-
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
Turn trans_fulfill_obligation
into a query
#44967
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
src/librustc/traits/trans/mod.rs
Outdated
/// Assumes that this is run after the entire crate has been successfully type-checked. | ||
pub fn trans_fulfill_obligation<'a, 'tcx>(ty: TyCtxt<'a, 'tcx, 'tcx>, | ||
(def_id, param_env, trait_ref): | ||
(DefId, ty::ParamEnv<'tcx>, ty::PolyTraitRef<'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.
I changed this to take a DefId
instead of a Span
because it looked like all of the other queries used DefId
and not Span
s. However, there were two places where DUMMY_SP
was passed in. I changed those to use DefId
s that seemed appropriate but I'm not sure. I'll indicate those below.
If that wasn't the right thing to do, I can revert it.
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, @nikomatsakis would know more about how the span here is actually used.
src/librustc_trans/monomorphize.rs
Outdated
@@ -113,7 +111,7 @@ fn resolve_associated_item<'a, 'tcx>( | |||
|
|||
let trait_ref = ty::TraitRef::from_method(tcx, trait_id, rcvr_substs); | |||
let vtbl = tcx.trans_fulfill_obligation( | |||
DUMMY_SP, ty::ParamEnv::empty(traits::Reveal::All), ty::Binder(trait_ref)); | |||
(trait_id, ty::ParamEnv::empty(traits::Reveal::All), ty::Binder(trait_ref))); |
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 was the first place DUMMY_SP
was passed in.
src/librustc_trans/monomorphize.rs
Outdated
substs: tcx.mk_substs_trait(source_ty, &[target_ty]) | ||
}); | ||
|
||
match tcx.trans_fulfill_obligation( | ||
DUMMY_SP, ty::ParamEnv::empty(traits::Reveal::All), trait_ref) { | ||
(def_id, ty::ParamEnv::empty(traits::Reveal::All), trait_ref)) { |
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 was the other place.
fn hash_stable<W: StableHasherResult>(&self, | ||
hcx: &mut StableHashingContext<'gcx>, | ||
hasher: &mut StableHasher<W>) { | ||
use traits::Vtable::*; |
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.
The enum discriminant also needs to be hashed:
mem::discriminant(self).hash_stable(hcx, hasher);
src/librustc/ich/impls_ty.rs
Outdated
fn hash_stable<W: StableHasherResult>(&self, | ||
hcx: &mut StableHashingContext<'gcx>, | ||
hasher: &mut StableHasher<W>) { | ||
self.impl_def_id.hash_stable(hcx, hasher); |
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.
So what we usually do here is use an exhaustive destructuring let
statement, so in case a field gets added or removed, we don't miss updating the HashStable
implementation:
let traits::VtableImplData {
impl_def_id,
substs,
ref nested,
} = *self;
impl_def_id.hash_stable(hcx, hasher);
substs.hash_stable(hcx, hasher);
nested.hash_stable(hcx, hasher);
That means a bit more typing but has proven to be very useful in catching oversights.
Very nice, thank you, @wesleywiser! Please update the I'll let @nikomatsakis do the rest of the review since trait selection is his field. |
r? @arielb1 I think you should just not pass the span/defid. It's just used for error reporting, and passing the span around as the query key will prevent all caching. |
I agree with @arielb1 -- the query key should just be |
src/librustc/traits/trans/mod.rs
Outdated
|
||
let span = ty.def_span(def_id); | ||
|
||
let obligation_cause = ObligationCause::misc(span, |
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.
here you can use ObligationCause::dummy()
instead
src/librustc/traits/trans/mod.rs
Outdated
debug!("Encountered ambiguity selecting `{:?}` during trans, \ | ||
presuming due to overflow", | ||
trait_ref); | ||
ty.sess.span_fatal(span, |
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 actually think this case .. hmm .. maybe cannot occur? That is, @arielb1, would that code you added that causes compilation to abort when types get too large perhaps kick in first?
☔ The latest upstream changes (presumably #44896) made this pull request unmergeable. Please resolve the merge conflicts. |
src/librustc/traits/trans/mod.rs
Outdated
(selection ambiguity)"); | ||
} | ||
Err(e) => { | ||
span_bug!(span, "Encountered error `{:?}` selecting `{:?}` during trans", |
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.
What should I do about this span here? Pass DUMMY_SP
?
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.
Just do a bug!
I think. I think for better error reporting we should just dump the query stack during each ICE.
dbddd4e
to
a9862b0
Compare
I believe I've resolved all of the review feedback. |
src/librustc/ty/maps/plumbing.rs
Outdated
@@ -765,6 +765,7 @@ pub fn force_from_dep_node<'a, 'gcx, 'lcx>(tcx: TyCtxt<'a, 'gcx, 'lcx>, | |||
DepKind::SpecializationGraph => { force!(specialization_graph_of, def_id!()); } | |||
DepKind::ObjectSafety => { force!(is_object_safe, def_id!()); } | |||
DepKind::TraitImpls => { force!(trait_impls_of, def_id!()); } | |||
DepKind::FulfillObligation => { force!(item_body_nested_bodies, def_id!()); } |
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.
Should this be forcing fulfull_obligation
instead?
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.
Fixed by making it a bug. I don't know how we'd recreate the query key so that seems appropriate to me, but I'm not 100% sure.
a9862b0
to
31f4b57
Compare
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.
So this looks right to me. The only question in my mind is if the one case -- which used to be a span_fatal
and is now a bug!
is truly a bug. If not, I suspect that we should convert the query to yield a Result
or Option
or something, and let the caller report the problem.
@bors r+ |
📌 Commit 31f4b57 has been approved by |
⌛ Testing commit 31f4b57 with merge bf27afeb1a9cf122bd5b2cdfbc765e7f02840119... |
💔 Test failed - status-travis |
Android builder failed. Seems related to some kind of network issue?
|
@bors retry
|
⌛ Testing commit 31f4b57 with merge 58bb6295629d03131e13923d939ef1401efb4451... |
💔 Test failed - status-travis |
Not sure what this means:
|
@bors retry LLDB segfault. |
…tsakis Turn `trans_fulfill_obligation` into a query Part of #44891
☀️ Test successful - status-appveyor, status-travis |
Part of #44891