[compiler][rfc] Hacky retry pipeline for fire #32164
Merged
+617
−90
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
React Core Team
mofeiZ
commented
Jan 22, 2025
Comment on lines
29
to
41
| 8 | useEffect(() => { | ||
| > 9 | fire(foo(props), bar); | ||
| | ^^^^^^^^^^^^^^^^^^^^^ InvalidReact: Cannot compile `fire`. fire() can only take in a single call expression as an argument but received multiple arguments (9:9) | ||
|
|
||
| InvalidReact: Cannot compile `fire`. fire() can only take in a single call expression as an argument but received a spread argument (10:10) | ||
|
|
||
| InvalidReact: Cannot compile `fire`. `fire()` can only receive a function call such as `fire(fn(a,b)). Method calls and other expressions are not allowed (11:11) | ||
|
|
||
| InvalidReact: Cannot compile `fire`. `fire()` can only receive a function call such as `fire(fn(a,b)). Method calls and other expressions are not allowed (12:12) | ||
| 10 | fire(...foo); | ||
| 11 | fire(bar); | ||
| 12 | fire(props.foo()); | ||
| ``` |
There was a problem hiding this comment.
Note that we continue to emit fire-related bailouts
mofeiZ
commented
Jan 22, 2025
Comment on lines
27
to
42
| // @enableFire | ||
| import { fire } from "react"; | ||
|
|
||
| function Component({ props, bar }) { | ||
| "use no memo"; | ||
| const foo = () => { | ||
| console.log(props); | ||
| }; | ||
| useEffect(() => { | ||
| fire(foo(props)); | ||
| fire(foo()); | ||
| fire(bar()); | ||
| }); | ||
|
|
||
| return null; | ||
| } |
There was a problem hiding this comment.
This is a todo fixture because "use no memo" directives probably should directly invoke the retry pipeline (e.g. no memo, no validation, just lower -> transformFire -> codegen)
|
Re the "hacky" framing of this in the PR title: I think this is fine. I can see having something like a compilation or output mode that we use when running the pipeline. Rather than changing environment settings when we re-run, various passes could take effect based on the combination of the mode + env flags. The modes might be:
|
Start of a simple retry pipeline. Would love feedback on how we implement this to be extensible to other compiler non-memoization features (e.g. inlineJSX)
github-actions bot
pushed a commit
to code/lib-react
that referenced
this pull request
Feb 1, 2025
Hacky retry pipeline for when transforming `fire(...)` calls encounters validation, todo, or memoization invariant bailouts. Would love feedback on how we implement this to be extensible to other compiler non-memoization features (e.g. inlineJSX) Some observations: - Compiler "front-end" passes (e.g. lower, type, effect, and mutability inferences) should be shared for all compiler features -- memo and otherwise - Many passes (anything dealing with reactive scope ranges, scope blocks / dependencies, and optimizations such as ReactiveIR facebook#31974) can be left out of the retry pipeline. This PR hackily skips memoization features by removing reactive scope creation, but we probably should restructure the pipeline to skip these entirely on a retry - We should maintain a canonical set of "validation flags" Note the newly added fixtures are prefixed with `bailout-...` when the retry fire pipeline is used. These fixture outputs contain correctly inserted `useFire` calls and no memoization. DiffTrain build for [152bfe3](facebook@152bfe3)
github-actions bot
pushed a commit
to code/lib-react
that referenced
this pull request
Feb 1, 2025
Hacky retry pipeline for when transforming `fire(...)` calls encounters validation, todo, or memoization invariant bailouts. Would love feedback on how we implement this to be extensible to other compiler non-memoization features (e.g. inlineJSX) Some observations: - Compiler "front-end" passes (e.g. lower, type, effect, and mutability inferences) should be shared for all compiler features -- memo and otherwise - Many passes (anything dealing with reactive scope ranges, scope blocks / dependencies, and optimizations such as ReactiveIR facebook#31974) can be left out of the retry pipeline. This PR hackily skips memoization features by removing reactive scope creation, but we probably should restructure the pipeline to skip these entirely on a retry - We should maintain a canonical set of "validation flags" Note the newly added fixtures are prefixed with `bailout-...` when the retry fire pipeline is used. These fixture outputs contain correctly inserted `useFire` calls and no memoization. DiffTrain build for [152bfe3](facebook@152bfe3)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hacky retry pipeline for when transforming
fire(...)calls encounters validation, todo, or memoization invariant bailouts. Would love feedback on how we implement this to be extensible to other compiler non-memoization features (e.g. inlineJSX)Some observations:
Note the newly added fixtures are prefixed with
bailout-...when the retry fire pipeline is used. These fixture outputs contain correctly inserteduseFirecalls and no memoization.