-
Notifications
You must be signed in to change notification settings - Fork 13.9k
Improve resolution of associated types in declarative macros 2.0 #44818
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
Conversation
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.
Hm, actually adjust doesn't require the NodeId if we need only the adjusted ident, so it looks like specialization can be fixed as well.
70fab20 to
f75497d
Compare
|
Updated with a fix for specialization. There are still plenty of unhygienic comparisons to fix (see loops through |
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.
Excellent!
r=me modulo optional comment.
src/librustc/ty/mod.rs
Outdated
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.
def_def_id "should" be the DefId of supposed definition's parent, i.e. the scope (module, enum, struct, trait, or impl) in which we are resolving use_name (the name of the the item, variant, field, trait item, or impl item, resp.).
However, I believe this distinction only makes a difference when resolving in modules, so we can probably safely use the semantics in this PR for resolution that happens after resolve.
|
cc @nrc |
|
Rebased + used trait DefIds in accordance with #44818 (comment) |
|
📌 Commit 2d9161d has been approved by |
Improve resolution of associated types in declarative macros 2.0 Make various identifier comparisons for associated types (and sometimes other associated items) hygienic. Now declarative macros 2.0 can use `Self::AssocTy`, `TyParam::AssocTy`, `Trait<AssocTy = u8>` where `AssocTy` is an associated type of a trait `Trait` visible from the macro. Also, `Trait` can now be implemented inside the macro and specialization should work properly (fixes #40847 (comment)). r? @jseyfried or @eddyb
|
💔 Test failed - status-travis |
|
|
Improve resolution of associated types in declarative macros 2.0 Make various identifier comparisons for associated types (and sometimes other associated items) hygienic. Now declarative macros 2.0 can use `Self::AssocTy`, `TyParam::AssocTy`, `Trait<AssocTy = u8>` where `AssocTy` is an associated type of a trait `Trait` visible from the macro. Also, `Trait` can now be implemented inside the macro and specialization should work properly (fixes #40847 (comment)). r? @jseyfried or @eddyb
|
☀️ Test successful - status-appveyor, status-travis |
Make various identifier comparisons for associated types (and sometimes other associated items) hygienic.
Now declarative macros 2.0 can use
Self::AssocTy,TyParam::AssocTy,Trait<AssocTy = u8>whereAssocTyis an associated type of a traitTraitvisible from the macro. Also,Traitcan now be implemented inside the macro and specialization should work properly (fixes #40847 (comment)).r? @jseyfried or @eddyb