-
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
fix: inline predicate_may_hold_fatal
and remove expect call in it
#112163
Conversation
.find(|o| !selcx.predicate_may_hold_fatal(o)); | ||
.find(|o| { | ||
selcx.evaluate_root_obligation(o).map_or( | ||
true, // Overflow has occurred, and treat the obligation as possibly holding. |
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.
An overflow is not an failing obligation. It is an ambiguity, and this is coherence, which must never treat an overflow as an error for soundness reasons.
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.
Understood. Thank you for explaining that.
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.
Specifically, an overflow represents a state of "we don't know whether or not a predicate holds because we didn't iterate deep enough" (where "deep enough" is sometimes infinitely deep -- as in this case -- or sometimes just because we set the recursion depth too low).
In coherence, we must never treat "we don't know" as "certainly does not hold", because in this code, "certainly does not hold" is used as proof that two impls may not overlap. The soundness of the program relies on coherence being correct.
Elsewhere in the compiler, outside of coherence, we can use overflows as "probably does not hold" because even if it did hold, we'd never be able to instantiate it during codegen. That's why other code, such as evaluate_obligation_no_overflow
treats this case as an error. The worst it can do is affect inference or the choice of a method during method dispatch.
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.
Thank you so much for your clear and concise explanation. I now have a better understanding of this topic.
@bors r+ |
…rrors fix: inline `predicate_may_hold_fatal` and remove expect call in it - Fixes rust-lang#105231 - Discussion: rust-lang#111985 (comment) r? `@compiler-errors`
Rollup of 7 pull requests Successful merges: - rust-lang#112163 (fix: inline `predicate_may_hold_fatal` and remove expect call in it) - rust-lang#112399 (Instantiate closure synthetic substs in root universe) - rust-lang#112443 (Opportunistically resolve regions in new solver) - rust-lang#112535 (reorder attributes to make miri-test-libstd work again) - rust-lang#112579 (Fix building libstd documentation on FreeBSD.) - rust-lang#112639 (Fix `dead_code_cgu` computation) - rust-lang#112642 (Handle interpolated literal errors) r? `@ghost` `@rustbot` modify labels: rollup
r? @compiler-errors