[compiler] Copy fixtures affected by new inference

Author: josephsavona

compiler/packages/babel-plugin-react-compiler/src/__tests__/fixtures/compiler/new-mutability/aliased-nested-scope-truncated-dep.expect.md

@@ -0,0 +1,221 @@
+
+## Input
+
+```javascript
+import {
+  Stringify,
+  mutate,
+  identity,
+  shallowCopy,
+  setPropertyByKey,
+} from 'shared-runtime';
+
+/**
+ * This fixture is similar to `bug-aliased-capture-aliased-mutate` and
+ * `nonmutating-capture-in-unsplittable-memo-block`, but with a focus on
+ * dependency extraction.
+ *
+ * NOTE: this fixture is currently valid, but will break with optimizations:
+ * - Scope and mutable-range based reordering may move the array creation
+ *     *after* the `mutate(aliasedObj)` call. This is invalid if mutate
+ *     reassigns inner properties.
+ * - RecycleInto or other deeper-equality optimizations may produce invalid
+ *     output -- it may compare the array's contents / dependencies too early.
+ * - Runtime validation for immutable values will break if `mutate` does
+ *     interior mutation of the value captured into the array.
+ *
+ * Before scope block creation, HIR looks like this:
+ *  //
+ *  // $1 is unscoped as obj's mutable range will be
+ *  // extended in a later pass
+ *  //
+ *  $1    = LoadLocal obj@0[0:12]
+ *  $2    = PropertyLoad $1.id
+ *  //
+ *  // $3 gets assigned a scope as Array is an allocating
+ *  // instruction, but this does *not* get extended or
+ *  // merged into the later mutation site.
+ *  // (explained in `bug-aliased-capture-aliased-mutate`)
+ *  //
+ *  $3@1  = Array[$2]
+ *  ...
+ *  $10@0 = LoadLocal shallowCopy@0[0, 12]
+ *  $11   = LoadGlobal mutate
+ *  $12   = $11($10@0[0, 12])
+ *
+ * When filling in scope dependencies, we find that it's incorrect to depend on
+ * PropertyLoads from obj as it hasn't completed its mutable range. Following
+ * the immutable / mutable-new typing system, we check the identity of obj to
+ * detect whether it was newly created (and thus mutable) in this render pass.
+ *
+ * HIR with scopes looks like this.
+ * bb0:
+ *  $1    = LoadLocal obj@0[0:12]
+ *  $2    = PropertyLoad $1.id
+ *  scopeTerminal deps=[obj@0] block=bb1 fallt=bb2
+ * bb1:
+ *  $3@1  = Array[$2]
+ *  goto bb2
+ * bb2:
+ *  ...
+ *
+ * This is surprising as deps now is entirely decoupled from temporaries used
+ * by the block itself. scope @1's instructions now reference a value (1)
+ * produced outside its scope range and (2) not represented in its dependencies
+ *
+ * The right thing to do is to ensure that all Loads from a value get assigned
+ * the value's reactive scope. This also requires track mutating and aliasing
+ * separately from scope range. In this example, that would correctly merge
+ * the scopes of $3 with obj.
+ * Runtime validation and optimizations such as ReactiveGraph-based reordering
+ * require this as well.
+ *
+ * A tempting fix is to instead extend $3's ReactiveScope range up to include
+ * $2 (the PropertyLoad). This fixes dependency deduping but not reordering
+ * and mutability.
+ */
+function Component({prop}) {
+  let obj = shallowCopy(prop);
+  const aliasedObj = identity(obj);
+
+  // [obj.id] currently is assigned its own reactive scope
+  const id = [obj.id];
+
+  // Writing to the alias may reassign to previously captured references.
+  // The compiler currently produces valid output, but this breaks with
+  // reordering, recycleInto, and other potential optimizations.
+  mutate(aliasedObj);
+  setPropertyByKey(aliasedObj, 'id', prop.id + 1);
+
+  return <Stringify id={id} />;
+}
+
+export const FIXTURE_ENTRYPOINT = {
+  fn: Component,
+  params: [{prop: {id: 1}}],
+  sequentialRenders: [{prop: {id: 1}}, {prop: {id: 1}}, {prop: {id: 2}}],
+};
+
+```
+
+## Code
+
+```javascript
+import { c as _c } from "react/compiler-runtime";
+import {
+  Stringify,
+  mutate,
+  identity,
+  shallowCopy,
+  setPropertyByKey,
+} from "shared-runtime";
+
+/**
+ * This fixture is similar to `bug-aliased-capture-aliased-mutate` and
+ * `nonmutating-capture-in-unsplittable-memo-block`, but with a focus on
+ * dependency extraction.
+ *
+ * NOTE: this fixture is currently valid, but will break with optimizations:
+ * - Scope and mutable-range based reordering may move the array creation
+ *     *after* the `mutate(aliasedObj)` call. This is invalid if mutate
+ *     reassigns inner properties.
+ * - RecycleInto or other deeper-equality optimizations may produce invalid
+ *     output -- it may compare the array's contents / dependencies too early.
+ * - Runtime validation for immutable values will break if `mutate` does
+ *     interior mutation of the value captured into the array.
+ *
+ * Before scope block creation, HIR looks like this:
+ *  //
+ *  // $1 is unscoped as obj's mutable range will be
+ *  // extended in a later pass
+ *  //
+ *  $1    = LoadLocal obj@0[0:12]
+ *  $2    = PropertyLoad $1.id
+ *  //
+ *  // $3 gets assigned a scope as Array is an allocating
+ *  // instruction, but this does *not* get extended or
+ *  // merged into the later mutation site.
+ *  // (explained in `bug-aliased-capture-aliased-mutate`)
+ *  //
+ *  $3@1  = Array[$2]
+ *  ...
+ *  $10@0 = LoadLocal shallowCopy@0[0, 12]
+ *  $11   = LoadGlobal mutate
+ *  $12   = $11($10@0[0, 12])
+ *
+ * When filling in scope dependencies, we find that it's incorrect to depend on
+ * PropertyLoads from obj as it hasn't completed its mutable range. Following
+ * the immutable / mutable-new typing system, we check the identity of obj to
+ * detect whether it was newly created (and thus mutable) in this render pass.
+ *
+ * HIR with scopes looks like this.
+ * bb0:
+ *  $1    = LoadLocal obj@0[0:12]
+ *  $2    = PropertyLoad $1.id
+ *  scopeTerminal deps=[obj@0] block=bb1 fallt=bb2
+ * bb1:
+ *  $3@1  = Array[$2]
+ *  goto bb2
+ * bb2:
+ *  ...
+ *
+ * This is surprising as deps now is entirely decoupled from temporaries used
+ * by the block itself. scope @1's instructions now reference a value (1)
+ * produced outside its scope range and (2) not represented in its dependencies
+ *
+ * The right thing to do is to ensure that all Loads from a value get assigned
+ * the value's reactive scope. This also requires track mutating and aliasing
+ * separately from scope range. In this example, that would correctly merge
+ * the scopes of $3 with obj.
+ * Runtime validation and optimizations such as ReactiveGraph-based reordering
+ * require this as well.
+ *
+ * A tempting fix is to instead extend $3's ReactiveScope range up to include
+ * $2 (the PropertyLoad). This fixes dependency deduping but not reordering
+ * and mutability.
+ */
+function Component(t0) {
+  const $ = _c(4);
+  const { prop } = t0;
+  let t1;
+  if ($[0] !== prop) {
+    const obj = shallowCopy(prop);
+    const aliasedObj = identity(obj);
+    let t2;
+    if ($[2] !== obj) {
+      t2 = [obj.id];
+      $[2] = obj;
+      $[3] = t2;
+    } else {
+      t2 = $[3];
+    }
+    const id = t2;
+
+    mutate(aliasedObj);
+    setPropertyByKey(aliasedObj, "id", prop.id + 1);
+
+    t1 = <Stringify id={id} />;
+    $[0] = prop;
+    $[1] = t1;
+  } else {
+    t1 = $[1];
+  }
+  return t1;
+}
+
+export const FIXTURE_ENTRYPOINT = {
+  fn: Component,
+  params: [{ prop: { id: 1 } }],
+  sequentialRenders: [
+    { prop: { id: 1 } },
+    { prop: { id: 1 } },
+    { prop: { id: 2 } },
+  ],
+};
+
+```
+      
+### Eval output
+(kind: ok) <div>{"id":[1]}</div>
+<div>{"id":[1]}</div>
+<div>{"id":[2]}</div>

compiler/packages/babel-plugin-react-compiler/src/__tests__/fixtures/compiler/new-mutability/aliased-nested-scope-truncated-dep.tsx

@@ -0,0 +1,93 @@
+import {
+  Stringify,
+  mutate,
+  identity,
+  shallowCopy,
+  setPropertyByKey,
+} from 'shared-runtime';
+
+/**
+ * This fixture is similar to `bug-aliased-capture-aliased-mutate` and
+ * `nonmutating-capture-in-unsplittable-memo-block`, but with a focus on
+ * dependency extraction.
+ *
+ * NOTE: this fixture is currently valid, but will break with optimizations:
+ * - Scope and mutable-range based reordering may move the array creation
+ *     *after* the `mutate(aliasedObj)` call. This is invalid if mutate
+ *     reassigns inner properties.
+ * - RecycleInto or other deeper-equality optimizations may produce invalid
+ *     output -- it may compare the array's contents / dependencies too early.
+ * - Runtime validation for immutable values will break if `mutate` does
+ *     interior mutation of the value captured into the array.
+ *
+ * Before scope block creation, HIR looks like this:
+ *  //
+ *  // $1 is unscoped as obj's mutable range will be
+ *  // extended in a later pass
+ *  //
+ *  $1    = LoadLocal obj@0[0:12]
+ *  $2    = PropertyLoad $1.id
+ *  //
+ *  // $3 gets assigned a scope as Array is an allocating
+ *  // instruction, but this does *not* get extended or
+ *  // merged into the later mutation site.
+ *  // (explained in `bug-aliased-capture-aliased-mutate`)
+ *  //
+ *  $3@1  = Array[$2]
+ *  ...
+ *  $10@0 = LoadLocal shallowCopy@0[0, 12]
+ *  $11   = LoadGlobal mutate
+ *  $12   = $11($10@0[0, 12])
+ *
+ * When filling in scope dependencies, we find that it's incorrect to depend on
+ * PropertyLoads from obj as it hasn't completed its mutable range. Following
+ * the immutable / mutable-new typing system, we check the identity of obj to
+ * detect whether it was newly created (and thus mutable) in this render pass.
+ *
+ * HIR with scopes looks like this.
+ * bb0:
+ *  $1    = LoadLocal obj@0[0:12]
+ *  $2    = PropertyLoad $1.id
+ *  scopeTerminal deps=[obj@0] block=bb1 fallt=bb2
+ * bb1:
+ *  $3@1  = Array[$2]
+ *  goto bb2
+ * bb2:
+ *  ...
+ *
+ * This is surprising as deps now is entirely decoupled from temporaries used
+ * by the block itself. scope @1's instructions now reference a value (1)
+ * produced outside its scope range and (2) not represented in its dependencies
+ *
+ * The right thing to do is to ensure that all Loads from a value get assigned
+ * the value's reactive scope. This also requires track mutating and aliasing
+ * separately from scope range. In this example, that would correctly merge
+ * the scopes of $3 with obj.
+ * Runtime validation and optimizations such as ReactiveGraph-based reordering
+ * require this as well.
+ *
+ * A tempting fix is to instead extend $3's ReactiveScope range up to include
+ * $2 (the PropertyLoad). This fixes dependency deduping but not reordering
+ * and mutability.
+ */
+function Component({prop}) {
+  let obj = shallowCopy(prop);
+  const aliasedObj = identity(obj);
+
+  // [obj.id] currently is assigned its own reactive scope
+  const id = [obj.id];
+
+  // Writing to the alias may reassign to previously captured references.
+  // The compiler currently produces valid output, but this breaks with
+  // reordering, recycleInto, and other potential optimizations.
+  mutate(aliasedObj);
+  setPropertyByKey(aliasedObj, 'id', prop.id + 1);
+
+  return <Stringify id={id} />;
+}
+
+export const FIXTURE_ENTRYPOINT = {
+  fn: Component,
+  params: [{prop: {id: 1}}],
+  sequentialRenders: [{prop: {id: 1}}, {prop: {id: 1}}, {prop: {id: 2}}],
+};