-
Notifications
You must be signed in to change notification settings - Fork 13.8k
Turn trans_fulfill_obligation
into a query
#44967
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
(rust_highfive has picked a reviewer for you, use r? to override) |
src/librustc/traits/trans/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.
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
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
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.
src/librustc/ich/impls_ty.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.
The enum discriminant also needs to be hashed:
mem::discriminant(self).hash_stable(hcx, hasher);
src/librustc/ich/impls_ty.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.
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
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
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
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
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