refactor(ast): AstBuilder::move_* methods use TakeIn
#10001
Merged
Conversation
This file contains hidden or 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
Member
Author
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. |
github-actions
bot
added
A-ast
CodSpeed Instrumentation Performance ReportMerging #10001 will not alter performanceComparing Summary
|
overlookmotel
force-pushed
the
03-24-refactor_ast_astbuilder_move__methods_use_takein_
branch
from
9f70792 to
5b79ba7
Compare
overlookmotel
force-pushed
the
03-22-feat_allocator_takein_trait
branch
from
8c4fd76 to
24b0e8a
Compare
graphite-app
bot
changed the base branch from
03-22-feat_allocator_takein_trait
to
graphite-base/10001
Member
Merge activity
|
`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.
graphite-app
bot
force-pushed
the
03-24-refactor_ast_astbuilder_move__methods_use_takein_
branch
from
5b79ba7 to
5f45005
Compare
graphite-app
bot
deleted the
03-24-refactor_ast_astbuilder_move__methods_use_takein_
branch
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.
AstBuilder::move_*methods useTakeIn::take_in(added in #9969) to replace nodes with dummy nodes.take_inwill 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 singleAstBuilder::takemethod which is generic overT: 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.
DeclarationandFunctionrequire allocating 56 bytes into arena,ArrowFunctionExpressionallocates 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 anExpressionorStatementinstead (only 8 bytes). We also want to avoid inadvertently adding further expensivetake_incalls, which a blanketAstBuilder::takemethod would make it easy to do.