-
-
Notifications
You must be signed in to change notification settings - Fork 771
refactor(ast): replace AstBuilder::move_* methods with take
#9970
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
refactor(ast): replace AstBuilder::move_* methods with take
#9970
Conversation
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
CodSpeed Instrumentation Performance ReportMerging #9970 will create unknown performance changesComparing Summary
Benchmarks breakdown
|
6711ae3 to
cd29674
Compare
1b55db0 to
0b7666d
Compare
cd29674 to
d9b1775
Compare
db93324 to
bf9c9fb
Compare
d9b1775 to
46d3858
Compare
bf9c9fb to
682d612
Compare
`AstBuilder::move_*` methods use `TakeIn::take_in` (added in #9969) to replace nodes with dummy nodes. `take_in` will always generate a dummy in whatever way minimizes the size and number of allocations required. It would be possible to replace all the `move_*` methods with a single `AstBuilder::take` method which is generic over `T: TakeIn` (#9970). But have opted not to do that, because it's useful to be able to see in calling code what type of node is being replaced. Some nodes are quite expensive to create a dummy for (e.g. `Declaration` and `Function` require allocating 56 bytes into arena, `ArrowFunctionExpression` allocates 128 bytes in 2 separate allocations), so it's useful to see where we're doing that, so we can try to replace them with cheaper operations e.g. replacing an `Expression` or `Statement` instead (only 8 bytes). We also want to avoid inadvertently adding further expensive `take_in` calls, which a blanket `AstBuilder::take` method would make it easy to do.

No description provided.