-
Notifications
You must be signed in to change notification settings - Fork 14k
Safe Transmute: Fix ICE (Inconsistent is_transmutable result) #113867
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
Safe Transmute: Fix ICE (Inconsistent is_transmutable result) #113867
Conversation
|
r? @wesleywiser (rustbot has picked a reviewer for you, use r? to override) |
|
Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
1416a53 to
8b56a0c
Compare
compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs
Outdated
Show resolved
Hide resolved
|
r? @lcnr |
8b56a0c to
f45177e
Compare
This patch updates the code that constructs the `Assume` type to return an error instead of silently falling back to a default `Assume`. This fixes an ICE where error reporting would get a different `is_transmutable` result that is inconsistent with the original one computed during trait confirmation. Fixes rust-lang#110969
f45177e to
98ddc0f
Compare
|
@rustbot ready |
| self.tcx().erase_regions(self.tcx().erase_late_bound_regions(obligation.predicate)); | ||
|
|
||
| let Some(assume) = rustc_transmute::Assume::from_const( | ||
| let Some(Ok(assume)) = rustc_transmute::Assume::from_const( |
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.
for None you have to return ambiguity, not Err(Unimplemented) 🤔
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.
Is there an existing way to represent ambiguity in the current solver? Just return an empty list of candidates? Was going through the code in the select directory, but it's not clear to me
| let assume = match maybe_assume { | ||
| Some(Ok(assume)) => assume, | ||
| Some(Err(_guar)) => return Err(NoSolution), | ||
| None => return Err(NoSolution), |
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.
same here
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.
Since NoSolution was just a struct, I created a new enum QueryError so I could return QueryError::NoSolution or QueryError::Ambiguous. But the change might be too invasive. Let me know what you think! I made the change in a separate commit.
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.
please keep using NoSolution. Ambiguity in the new solver is represented as Ok with Certainty::Maybe(MaybeCause::Ambiguity)/Certainty::AMBIGUOUS.
use ecx.evaluate_added_goals_and_make_query_response(Certainty::AMBIGUOUS) 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.
Thanks, that makes a lot more sense! evaluate_added_goals_and_make_query_response doesn't exist, did you mean evaluate_added_goals_and_make_canonical_response?
|
Some changes occurred in engine.rs, potentially modifying the public API of |
d19279c to
77c542c
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.
this feels somewhat dangerous to me 🤷 i guess it's fine because fulfillment error reporting uses delay_span_bug so if it's wrong we just ICE
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 it's not ideal :/ I could emit a warning or something maybe 🤔
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.
ah, maybe add tcx.sess.delay_span_bug("expected another error here") or sth to get a better ICE if it does go wrong. THis should simplify debugging if it blows up
compiler/rustc_transmute/src/lib.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.
nit: rename the variant to ErrorGuaranteed 🤔
compiler/rustc_transmute/src/lib.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.
| ) -> Option<Result<Self, ErrorGuaranteed>> { | |
| ) -> Result<Option<Self>, ErrorGuaranteed> { |
general convention: errors are "more important/immediate/whatever" than ambiguity
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.
thanks, I didn't know this convention but it makes a lot of sense!
compiler/rustc_transmute/src/lib.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 import should live in the rustc module, shouldn't it? I guess why is the Reason enum outside of rustc 🤔 i would assume that we mostly need this when doing "rustc stuff"?
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, we are trying to make it so that rustc_transmute can build independently of rustc, so pulling in ErrorGuaranteed is not ideal. I'm going to add a FIXME for this. It's getting more and more coupled as I make fixes/improvements 😮
77c542c to
9702a5d
Compare
This comment has been minimized.
This comment has been minimized.
This patch updates a couple spots in the trait selection (in both solvers) to return ambiguity instead of an error.
9702a5d to
641a43d
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.
ah, maybe add tcx.sess.delay_span_bug("expected another error here") or sth to get a better ICE if it does go wrong. THis should simplify debugging if it blows up
| return Err(Unimplemented); | ||
| ) { | ||
| Ok(Some(assume)) => assume, | ||
| Ok(None) => return Ok(vec![]), |
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.
that's wrong. We would consider transmute to always be possible if the assume is ambig '^^ it's annoying because confirmation cannot handle ambiguity. We have to instead check that we can build the Assume in assembly and then we can ICE here
|
☔ The latest upstream changes (presumably #115803) made this pull request unmergeable. Please resolve the merge conflicts. |
|
@bryangarza any updates on this? |
|
Ping from triage: I'm closing this due to inactivity, Please reopen when you are ready to continue with this. @rustbot label: +S-inactive |
This patch updates the code that constructs the
Assumetype to return an error instead of silently falling back to a defaultAssume. This fixes an ICE where error reporting would get a differentis_transmutableresult that is inconsistent with the original one computed during trait confirmation.Fixes #110969