Skip to content
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

Merged
merged 1 commit into from
Jun 16, 2023

Conversation

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 1, 2023
.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.
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

@compiler-errors compiler-errors Jun 16, 2023

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.

Copy link
Contributor Author

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.

@compiler-errors
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Jun 16, 2023

📌 Commit b792198 has been approved by compiler-errors

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 16, 2023
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Jun 16, 2023
…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`
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 16, 2023
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
@bors bors merged commit c563296 into rust-lang:master Jun 16, 2023
@rustbot rustbot added this to the 1.72.0 milestone Jun 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
4 participants