-
-
Notifications
You must be signed in to change notification settings - Fork 484
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
feat(traverse): add generate_binding
and generate_binding_current_scope
APIs in context
#6805
Conversation
Your org has enabled the Graphite merge queue for merging into mainAdd the label “0-merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix. You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link. |
This stack of pull requests is managed by Graphite. Learn more about stacking. |
generate_binding
and generate_binding_current_scope
APIs in context
CodSpeed Performance ReportMerging #6805 will not alter performanceComparing Summary
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it'd be preferable if generate_binding
took an Atom
instead of a CompactStr
. If it's an existing var name (which it must be, otherwise we'd be using generate_uid
), an Atom
will already exist in the arena for this symbol name, so we'd be better off reusing it. I'll submit that change in a follow-on PR.
This business with juggling CompactStr
s and Atom
s is a real pain!
Merge activity
|
…scope` APIs in context (#6805) These two APIs are used to create a symbol with the provided symbol name, The difference from `generate_uid` is that we don't need to create a unique name for the symbol. If you have a better method name for this, Feel free to edit this PR directly
aad68b0
to
c96e739
Compare
…6830) Follow-up after #6805. `TraverseCtx::generate_binding` take an `Atom` instead of a `CompactStr`. If it's an existing var name (which it must be, otherwise we'd be using `TraverseCtx::generate_uid`), an `Atom` will already exist in the arena for this symbol name, so we'd be better off reusing it, rather than writing the same `Atom` into the arena again.
These two APIs are used to create a symbol with the provided symbol name, The difference from
generate_uid
is that we don't need to create a unique name for the symbol.If you have a better method name for this, Feel free to edit this PR directly