You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adds a mechanism where if we can't determine a precise set of aliasing (data flow) effects for a function signature, to fall back to treating function expressions as general-purpose mutable values. Concretely:
* `InferMutationAliasingEffects` has an optimization where if you're `Apply`-ing a specific, known function expression, that we use the inferred signature for that function. Now we only use this mode _if_ we could infer a precise signature.
* `InferFunctionExpressionAliasingSignature` now bails out if there is a phi with a backedge, since we weren't handling this case.
See the repro for this case: i confirmed that it was previously incorrect.
Also adds a repro for a case of an invalid array length, which exposes the fact that InferFunctionExpressionAliasingSignatures is accumulating aliases w/o reducing them in any way. A complex enough function expression can lead to the accumulated array of effects overflowing the max array size. Fix in the next PR.
Copy file name to clipboardExpand all lines: compiler/packages/babel-plugin-react-compiler/src/Inference/InferFunctionExpressionAliasingEffectsSignature.ts
+25-11Lines changed: 25 additions & 11 deletions
Original file line number
Diff line number
Diff line change
@@ -5,9 +5,16 @@
5
5
* LICENSE file in the root directory of this source tree.
Copy file name to clipboardExpand all lines: compiler/packages/babel-plugin-react-compiler/src/Inference/MUTABILITY_ALIASING_MODEL.md
+10-10Lines changed: 10 additions & 10 deletions
Original file line number
Diff line number
Diff line change
@@ -514,9 +514,9 @@ Intuition: these effects are inverses of each other (capturing into an object, e
514
514
Capture then CreatFrom is equivalent to Alias: we have to assume that the result _is_ the original value and that a local mutation of the result could mutate the original.
515
515
516
516
```js
517
-
consty= [x]; // capture
518
-
constz=y[0]; // createfrom
519
-
mutate(z); // this clearly can mutate x, so the result must be one of Assign/Alias/CreateFrom
517
+
constb= [a]; // capture
518
+
constc=b[0]; // createfrom
519
+
mutate(c); // this clearly can mutate a, so the result must be one of Assign/Alias/CreateFrom
520
520
```
521
521
522
522
We use Alias as the return type because the mutability kind of the result is not derived from the source value (there's a fresh object in between due to the capture), so the full set of effects in practice would be a Create+Alias.
@@ -528,17 +528,17 @@ CreateFrom c <- b
528
528
Alias c <- a
529
529
```
530
530
531
-
Meanwhile the opposite direction preservers the capture, because the result is not the same as the source:
531
+
Meanwhile the opposite direction preserves the capture, because the result is not the same as the source:
532
532
533
533
```js
534
-
consty=x[0]; // createfrom
535
-
constz= [y]; // capture
536
-
mutate(z); // does not mutate x, so the result must be Capture
534
+
constb=a[0]; // createfrom
535
+
constc= [b]; // capture
536
+
mutate(c); // does not mutate a, so the result must be Capture
0 commit comments