-
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
Upgrade ProjectionTy's Name to a DefId #42297
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
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.
This looks pretty good. I left a few requests for changes. The main question is whether we care about hygiene for these item lookups (as you noted) -- I would guess no, but perhaps @jseyfried or @petrochenkov knows better?
src/librustc/ty/structural_impls.rs
Outdated
@@ -771,7 +768,8 @@ impl<'tcx> TypeFoldable<'tcx> for ty::ProjectionTy<'tcx> { | |||
fn super_fold_with<'gcx: 'tcx, F: TypeFolder<'gcx, 'tcx>>(&self, folder: &mut F) -> Self { | |||
ty::ProjectionTy { | |||
trait_ref: self.trait_ref.fold_with(folder), | |||
item_name: self.item_name, | |||
// FIXME(tschottdorf): is this correct, or a case for tls::with? |
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.
this is correct as is
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.
Done.
src/librustc/ty/sty.rs
Outdated
@@ -556,9 +556,39 @@ pub struct ProjectionTy<'tcx> { | |||
/// The trait reference `T as Trait<..>`. | |||
pub trait_ref: ty::TraitRef<'tcx>, | |||
|
|||
/// The name `N` of the associated type. | |||
pub item_name: Name, | |||
/// The DefId of the the associated type `N`. |
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 would say "The DefId of the TraitItem
for the associated type N
."
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.
PS kudos to you for commenting :)
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.
Done.
src/librustc/ty/sty.rs
Outdated
pub fn from_ref_and_name( | ||
tcx: TyCtxt, | ||
trait_ref: ty::TraitRef<'tcx>, | ||
item_name: Name) -> ProjectionTy<'tcx> { |
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.
Nit: formatting. I think that in this case, the ->
goes on next line, and I personally would put {
indented with pub
(so that body is clearly distinguished from the signature). But we don't have hard-and-fast rules here. You could also align with the open (
.
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.
Done (I think?)
src/librustc/ty/sty.rs
Outdated
// | ||
// let ident = self.tcx.adjust(item_name, def_id, self.body_id).0; | ||
// | ||
// (There is no body_id in scope here). Is the below incorrect? |
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.
Yeah, bother, I don't know how hygiene and "associated item lookup" are supposed to interact here. @jseyfried may have thoughts.
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.
Removed as per comment on main thread.
src/librustc/ty/sty.rs
Outdated
} | ||
|
||
impl<'a, 'tcx> ProjectionTy<'tcx> { | ||
pub fn from_ref_and_name( |
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.
Maybe add a comment here?
"Construct a ProjectionTy
by searching the trait from trait_ref
for the associated item named item_name
."
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.
Done.
src/librustc/ty/util.rs
Outdated
@@ -667,7 +667,8 @@ impl<'a, 'gcx, 'tcx, W> TypeVisitor<'tcx> for TypeIdHasher<'a, 'gcx, 'tcx, W> | |||
} | |||
TyProjection(ref data) => { | |||
self.def_id(data.trait_ref.def_id); | |||
self.hash(data.item_name.as_str()); | |||
// FIXME(tschottdorf): are there consequences to this change? |
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 actually need the first hash (of data.trait_ref.def_id
); the second should suffice, I think.
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.
Done.
ty::ProjectionTy::from_ref_and_name( | ||
tcx, | ||
trait_ref, | ||
Symbol::intern("Target"), |
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.
this is fine for now; eventually, though, we could make lang-items for the associated types from "well known" traits like this
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.
Ack, feel free to throw that my way at some point. I'm not sure what it would entail.
@arielb1 writes on IRC that we don't use hygiene for associated item lookup at present (which is also what I thought). This suggests @tschottdorf that the code for |
Part of rust-lang#42171, in preparation for downgrading the contained `TraitRef` to only its `substs`.
Thanks for the review! Comments addressed. |
@bors r+ |
📌 Commit e5e664f has been approved by |
Upgrade ProjectionTy's Name to a DefId Part of rust-lang#42171, in preparation for downgrading the contained `TraitRef` to only its `substs`. Some inline questions in the diff. Look for `FIXME(tschottdorf)`. These comments should be addressed before merging.
Upgrade ProjectionTy's Name to a DefId Part of rust-lang#42171, in preparation for downgrading the contained `TraitRef` to only its `substs`. Some inline questions in the diff. Look for `FIXME(tschottdorf)`. These comments should be addressed before merging.
Part of #42171, in preparation for downgrading the contained
TraitRef
toonly its
substs
.Some inline questions in the diff. Look for
FIXME(tschottdorf)
. These commentsshould be addressed before merging.