Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[compiler] Correctly insert (Arrow)FunctionExpressions #30446

Merged
merged 6 commits into from
Jul 24, 2024

Conversation

poteto
Copy link
Member

@poteto poteto commented Jul 24, 2024

Stack from ghstack (oldest at bottom):

Previously we would insert new (Arrow)FunctionExpressions as a sibling
of the original function. However this would break in the outlining case
as it would cause the original function expression's parent to become a
SequenceExpression, breaking a bunch of assumptions in the babel plugin.

To get around this, we synthesize a new VariableDeclaration to contain
the newly inserted function expression and therefore insert it as a true
sibling to the original function.

Yeah, it's kinda gross

[ghstack-poisoned]
Copy link

vercel bot commented Jul 24, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
react-compiler-playground ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jul 24, 2024 8:02pm

poteto added a commit that referenced this pull request Jul 24, 2024
Previously we would insert new (Arrow)FunctionExpressions as a sibling
of the original function. However this would break in the outlining case
as it would cause the original function expression's parent to become a
SequenceExpression, breaking a bunch of assumptions in the babel plugin.

To get around this, we synthesize a new VariableDeclaration to contain
the newly inserted function expression and therefore insert it as a true
sibling to the original function.

Yeah, it's kinda gross

ghstack-source-id: 95babb9810dd11adf9585efdd17988ec4b6eda56
Pull Request resolved: #30446
@facebook-github-bot facebook-github-bot added CLA Signed React Core Team Opened by a member of the React Core Team labels Jul 24, 2024
[ghstack-poisoned]
poteto added a commit that referenced this pull request Jul 24, 2024
Previously we would insert new (Arrow)FunctionExpressions as a sibling
of the original function. However this would break in the outlining case
as it would cause the original function expression's parent to become a
SequenceExpression, breaking a bunch of assumptions in the babel plugin.

To get around this, we synthesize a new VariableDeclaration to contain
the newly inserted function expression and therefore insert it as a true
sibling to the original function.

Yeah, it's kinda gross

ghstack-source-id: aefc2cdb2fa1b2f17fc6b9e5fc22b57ded78fd34
Pull Request resolved: #30446
[ghstack-poisoned]
poteto added a commit that referenced this pull request Jul 24, 2024
Previously we would insert new (Arrow)FunctionExpressions as a sibling
of the original function. However this would break in the outlining case
as it would cause the original function expression's parent to become a
SequenceExpression, breaking a bunch of assumptions in the babel plugin.

To get around this, we synthesize a new VariableDeclaration to contain
the newly inserted function expression and therefore insert it as a true
sibling to the original function.

Yeah, it's kinda gross

ghstack-source-id: b432abc3143a2a7551b9dd1886d60695f541b071
Pull Request resolved: #30446
[ghstack-poisoned]
poteto added a commit that referenced this pull request Jul 24, 2024
Previously we would insert new (Arrow)FunctionExpressions as a sibling
of the original function. However this would break in the outlining case
as it would cause the original function expression's parent to become a
SequenceExpression, breaking a bunch of assumptions in the babel plugin.

To get around this, we synthesize a new VariableDeclaration to contain
the newly inserted function expression and therefore insert it as a true
sibling to the original function.

Yeah, it's kinda gross

ghstack-source-id: 8a458917c1c314c5b94426238e9d9575e0b71e69
Pull Request resolved: #30446
Comment on lines 238 to 255
varDecl.insertAfter(
t.variableDeclaration('const', [
t.variableDeclarator(compiledFn.id, funcExpr),
]),
);
CompilerError.invariant(typeof varDecl.key === 'number', {
reason:
'Just Babel things: expected the VariableDeclaration containing the compiled function expression to have a number key',
loc: null,
});
const insertedCompiledFnVarDecl = varDecl.getSibling(varDecl.key + 1);
CompilerError.invariant(
insertedCompiledFnVarDecl.isVariableDeclaration(),
{
reason: 'Expected inserted sibling to be a VariableDeclaration',
loc: null,
},
);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: (please disregard if this is intentional to double check babel-things) I think we might be able to just use the return value of insertAfter instead of going through getSibling etc.

```

### Eval output
(kind: exception) Fixture not implemented
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Can we add a fixture entrypoint here?

export const FIXTURE_ENTRYPOINT = {
  fn: Component2,
  params: [
    {
      items: [
        {id: 2, name: 'foo'},
        {id: 3, name: 'bar'},
      ],
    },
  ],
};

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good call, thanks!

Copy link
Contributor

@mofeiZ mofeiZ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fix, this makes sense!

I'm a bit confused on the original outlining function-creation logic added by #30331 -- not sure why we want to insert function declarations / expressions / arrows based on the type of the component / hook function. But that's separate of this

[ghstack-poisoned]
poteto added a commit that referenced this pull request Jul 24, 2024
Previously we would insert new (Arrow)FunctionExpressions as a sibling
of the original function. However this would break in the outlining case
as it would cause the original function expression's parent to become a
SequenceExpression, breaking a bunch of assumptions in the babel plugin.

To get around this, we synthesize a new VariableDeclaration to contain
the newly inserted function expression and therefore insert it as a true
sibling to the original function.

Yeah, it's kinda gross

ghstack-source-id: cdf36f3913415ebad5a96896812ef58f3c5d0a26
Pull Request resolved: #30446
[ghstack-poisoned]
poteto added a commit that referenced this pull request Jul 24, 2024
Previously we would insert new (Arrow)FunctionExpressions as a sibling
of the original function. However this would break in the outlining case
as it would cause the original function expression's parent to become a
SequenceExpression, breaking a bunch of assumptions in the babel plugin.

To get around this, we synthesize a new VariableDeclaration to contain
the newly inserted function expression and therefore insert it as a true
sibling to the original function.

Yeah, it's kinda gross

ghstack-source-id: df13e3b439962b95af4bbd82ef4302624668faf7
Pull Request resolved: #30446
@poteto poteto merged commit 58fb44a into gh/poteto/36/base Jul 24, 2024
21 checks passed
poteto added a commit that referenced this pull request Jul 24, 2024
Previously we would insert new (Arrow)FunctionExpressions as a sibling
of the original function. However this would break in the outlining case
as it would cause the original function expression's parent to become a
SequenceExpression, breaking a bunch of assumptions in the babel plugin.

To get around this, we synthesize a new VariableDeclaration to contain
the newly inserted function expression and therefore insert it as a true
sibling to the original function.

Yeah, it's kinda gross

ghstack-source-id: df13e3b439962b95af4bbd82ef4302624668faf7
Pull Request resolved: #30446
@poteto poteto deleted the gh/poteto/36/head branch July 24, 2024 20:02
felixshiftellecon added a commit to felixshiftellecon/react that referenced this pull request Jul 24, 2024
Previously we would insert new (Arrow)FunctionExpressions as a sibling
of the original function. However this would break in the outlining case
as it would cause the original function expression's parent to become a
SequenceExpression, breaking a bunch of assumptions in the babel plugin.

To get around this, we synthesize a new VariableDeclaration to contain
the newly inserted function expression and therefore insert it as a true
sibling to the original function.

Yeah, it's kinda gross

ghstack-source-id: df13e3b439962b95af4bbd82ef4302624668faf7
Pull Request resolved: facebook#30446
@josephsavona
Copy link
Contributor

josephsavona commented Jul 24, 2024

Thanks for the fix. I think we can simplify this by always creating the outlined function as a function declaration at the top level of the program. The name is already guaranteed to be unique in the file so this won’t cause conflicts.

@josephsavona
Copy link
Contributor

not sure why we want to insert function declarations / expressions / arrows based on the type of the component / hook function. But that's separate of this

I reused the existing logic to create new functions and it didn’t seem to really matter in practice what type of function we created. But yeah we should change this to always produce a FunctionDeclaration for outlined functions.

poteto added a commit that referenced this pull request Jul 25, 2024
Addresses follow up feedback from #30446. Since the outlined function is
guaranteed to have a module-scoped unique identifier name, we can
simplify the insertion logic for the outlined function to always emit a
function declaration rather than switch based on the original function
type. This is fine because the outlined function is synthetic anyway.

ghstack-source-id: 0a4d1f7b0a5a34f8ed68c463b1a153c51c3ea75e
Pull Request resolved: #30464
poteto added a commit that referenced this pull request Jul 25, 2024
Addresses follow up feedback from #30446. Since the outlined function is
guaranteed to have a module-scoped unique identifier name, we can
simplify the insertion logic for the outlined function to always emit a
function declaration rather than switch based on the original function
type. This is fine because the outlined function is synthetic anyway.

ghstack-source-id: 0a4d1f7b0a5a34f8ed68c463b1a153c51c3ea75e
Pull Request resolved: #30464
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed React Core Team Opened by a member of the React Core Team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants