-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Don't compute block_def_map when there are only macros in expression position #7717
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
Labels
S-actionable
Someone could pick this issue up and work on it right now
Comments
bors bot
added a commit
to rust-analyzer/ungrammar
that referenced
this issue
Feb 18, 2021
27: Split out macro calls in item position r=matklad a=jonas-schievink This is needed in order to distinguish macro calls in expression position from calls in item position. Required for rust-lang/rust-analyzer#7717. Co-authored-by: Jonas Schievink <[email protected]>
Do we still want to do this? Not that I think either way, but we're lagging on |
Crap, I shouldn't have published that so eagerly, I ran into some issues while updating r-a |
bors bot
added a commit
to rust-analyzer/ungrammar
that referenced
this issue
Mar 15, 2021
30: Revert macro changes r=jonas-schievink a=jonas-schievink I came up with a less invasive solution for rust-lang/rust-analyzer#7717 bors r+ Co-authored-by: Jonas Schievink <[email protected]>
I reverted the ungrammar changes since I came up with a simpler way to achieve this: We "just" compute per-block ItemTrees and skip |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently we cannot distinguish between macro calls in item/statement vs. expression position, leading to unnecessary block_def_map computations. For example, in this code there's no need to compute block_def_map for the function block:
This is a very minor issue and is unlikely to impact performance or memory usage much.
The text was updated successfully, but these errors were encountered: