-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Use hir::Path instead of ast::Path in HIR Attribute's. #56480
Conversation
This comment has been minimized.
This comment has been minimized.
That's what I immediately thought - even if AST paths are removed, there still can be pieces of AST in tokens. Is it possible to |
Regarding attributes in HIR, I the long term goal is to have some semantic representation for attributes in HIR ( In that sense this PR is closer to the long term goal than #56492. |
☔ The latest upstream changes (presumably #56557) made this pull request unmergeable. Please resolve the merge conflicts. |
Triage; @eddyb Hello, have you been able to get back to this PR? |
Ping from triage @eddyb: What is the status of this PR? |
ping from triage @eddyb Unfortunately we haven't heard from you on this in a while, so I'm closing the PR to keep things tidy. Don't worry though, if you'll have time again in the future please reopen this PR, we'll be happy to review it again! |
The goal here was to avoid using
ast::Path
in the HIR and having serialization logic forast::{Ty,Expr,...}
(inside generic arguments), despite them not existing for attribute paths.We can't remove
Nonterminal
s "as easily", but webug!
for those already in some places.This seemed a trivial change at first, but now I'm not so sure, I've had to make a lot of code work on either AST or HIR
Attribute
s, using generics (over thePath
parameter).Maybe we should just have
path: Vec<Ident>
inAttribute
, instead of{ast,hir}::Path
?EDIT: opened #56492 for that variant.
r? @petrochenkov cc @nikomatsakis