-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Improve resolution of associated types in declarative macros 2.0 #44818
Conversation
-> impl Iterator<Item = NodeItem<ty::AssociatedItem>> + 'a { | ||
self.flat_map(move |node| { | ||
node.items(tcx).filter(move |item| { | ||
let item_ident = tcx.adjust(item.name, trait_def_id, impl_node_id).0; |
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
@@ -2282,6 +2282,13 @@ impl<'a, 'gcx, 'tcx> TyCtxt<'a, 'gcx, 'tcx> { | |||
} | |||
} | |||
|
|||
// Hygienically compare a use-site name (`use_name`) for a field or an associated item with its | |||
// supposed definition name (`def_name`). The method also needs the supposed definition's | |||
// `DefId` to perform comparison. |
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>
whereAssocTy
is an associated type of a traitTrait
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