-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Remove hir::Ident #33654
Remove hir::Ident #33654
Conversation
@@ -862,9 +865,14 @@ impl<'a> LoweringContext<'a> { | |||
PatKind::Wild => hir::PatKind::Wild, | |||
PatKind::Ident(ref binding_mode, pth1, ref sub) => { | |||
self.with_parent_def(p.id, |this| { | |||
let name = match this.resolver.get_resolution(p.id).map(|d| d.full_def()) { | |||
// Only pattern bindings are renamed |
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.
Why do we only sometimes rename here?
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.
We don't want to rename constants or unit variants/structs, that can also be represented with PatKind::Ident
due to parsing ambiguities, only fresh bindings.
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.
At this stage we are post-parsing and post-name resolution, so where do the remaining ambiguities get resolved? Put another way, in some sense this renaming must happen somewhere, where does it happen (and how)?
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'm not sure I understand the question.
At this stage we are post-parsing and post-name resolution, so where do the remaining ambiguities get resolved?
All ambiguities are resolved during name resolution, there's nothing ambiguous at this stage.
Put another way, in some sense this renaming must happen somewhere, where does it happen (and how)?
Renaming is done twice, once during name resolution, its results aren't saved anywhere, and once more during lowering to HIR, its results are persistent and kept in HIR.
Name
s in HIR need to be properly renamed to correctly treat cases like this, which in principle can be interpreted as requiring some rudimentary form of name resolution during type checking.
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.
If tables of "canonical bindings" were filled during the main name resolution pass and saved for later, then HIR could keep plain non-renamed Name
s for everything.
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.
thanks for the explanation!
☔ The latest upstream changes (presumably #33505) made this pull request unmergeable. Please resolve the merge conflicts. |
Do not rename invalid identifiers, they stop being invalid after renaming
Rebased. |
@bors: r+ |
📌 Commit 02a1eef has been approved by |
Remove last traces of identifier hygiene from HIR rust-lang@e783a0a removed the [last](rust-lang#33654 (comment)) [use](rust-lang#33654 (comment)) of hygiene at post-resolve compilation stages, so we can avoid renaming during lowering to HIR and just keep original names. r? @nrc
Now when name resolution is done on AST,
hir::Ident
is no longer necessary.See #30145 for more details.
r? @nrc