elaborate obligations in coherence by lcnr · Pull Request #124532 · rust-lang/rust
rustbot
added
S-waiting-on-review
labels
Apr 29, 2024
compiler-errors
added
T-types
and removed T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.labels
Apr 29, 2024
lcnr
mentioned this pull request
rustbot
added
A-testsuite
labels
May 10, 2024
bors
added
the
S-waiting-on-bors
label
May 13, 2024fmease added a commit to fmease/rust that referenced this pull request
May 13, 2024…er-errors
elaborate obligations in coherence
The following test currently does not pass coherence:
```rust
trait Super {}
trait Sub<T>: Super {}
trait Overlap<T> {}
impl<T, U: Sub<T>> Overlap<T> for U {}
impl<T> Overlap<T> for () {}
fn main() {}
```
We check whether `(): Sub<?t>` holds. This stalls with ambiguity as downstream crates may add an impl for `(): Sub<Local>`. However, its super trait bound `(): Super` cannot be implemented downstream, so this one is known not to hold.
By elaborating the bounds in the implicit negative overlap check, this now compiles. This is necessary to prevent breakage from enabling `-Znext-solver=coherence` (rust-lang#121848), see tests/ui/coherence/super-traits/super-trait-knowable-2.rs for more details.
r? `@compiler-errors`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
May 13, 2024…er-errors
elaborate obligations in coherence
The following test currently does not pass coherence:
```rust
trait Super {}
trait Sub<T>: Super {}
trait Overlap<T> {}
impl<T, U: Sub<T>> Overlap<T> for U {}
impl<T> Overlap<T> for () {}
fn main() {}
```
We check whether `(): Sub<?t>` holds. This stalls with ambiguity as downstream crates may add an impl for `(): Sub<Local>`. However, its super trait bound `(): Super` cannot be implemented downstream, so this one is known not to hold.
By elaborating the bounds in the implicit negative overlap check, this now compiles. This is necessary to prevent breakage from enabling `-Znext-solver=coherence` (rust-lang#121848), see tests/ui/coherence/super-traits/super-trait-knowable-2.rs for more details.
r? ``@compiler-errors``
bors added a commit to rust-lang-ci/rust that referenced this pull request
May 13, 2024…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#119515 (style-guide: Format single associated type `where` clauses on the same line) - rust-lang#119959 ([meta] Clarify prioritization alert) - rust-lang#123817 (Stabilize `seek_seek_relative`) - rust-lang#124532 (elaborate obligations in coherence) - rust-lang#125063 (Don't call `env::set_var` in `rustc_driver::install_ice_hook`) r? `@ghost` `@rustbot` modify labels: rollup
bors
added
S-waiting-on-author
and removed S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.labels
May 13, 2024
lcnr
mentioned this pull request
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
Jul 30, 2024…=compiler-errors elaborate unknowable goals A reimplemented version of rust-lang#124532 affecting only the new solver. Always trying to prove super traits ends up causing a fatal overflow error in diesel, so we cannot land this in the old solver. The following test currently does not pass coherence: ```rust trait Super {} trait Sub<T>: Super {} trait Overlap<T> {} impl<T, U: Sub<T>> Overlap<T> for U {} impl<T> Overlap<T> for () {} fn main() {} ``` We check whether `(): Sub<?t>` holds. This stalls with ambiguity as downstream crates may add an impl for `(): Sub<Local>`. However, its super trait bound `(): Super` cannot be implemented downstream, so this one is known not to hold. By trying to prove that all the super bounds of a trait before adding a coherence unknowable candidate, this compiles. This is necessary to prevent breakage from enabling `-Znext-solver=coherence` (rust-lang#121848), see tests/ui/coherence/super-traits/super-trait-knowable-2.rs for more details. The idea is that while there may be an impl of the trait itself we don't know about, if we're able to prove that a super trait is definitely not implemented, then that impl would also never apply/not be well-formed. This approach is different from rust-lang#124532 as it allows tests/ui/coherence/super-traits/super-trait-knowable-3.rs to compile. The approach in rust-lang#124532 only elaborating the root obligations while this approach tries it for all unknowable trait goals. r? `@compiler-errors`
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
Jul 30, 2024Rollup merge of rust-lang#127574 - lcnr:coherence-check-supertrait, r=compiler-errors elaborate unknowable goals A reimplemented version of rust-lang#124532 affecting only the new solver. Always trying to prove super traits ends up causing a fatal overflow error in diesel, so we cannot land this in the old solver. The following test currently does not pass coherence: ```rust trait Super {} trait Sub<T>: Super {} trait Overlap<T> {} impl<T, U: Sub<T>> Overlap<T> for U {} impl<T> Overlap<T> for () {} fn main() {} ``` We check whether `(): Sub<?t>` holds. This stalls with ambiguity as downstream crates may add an impl for `(): Sub<Local>`. However, its super trait bound `(): Super` cannot be implemented downstream, so this one is known not to hold. By trying to prove that all the super bounds of a trait before adding a coherence unknowable candidate, this compiles. This is necessary to prevent breakage from enabling `-Znext-solver=coherence` (rust-lang#121848), see tests/ui/coherence/super-traits/super-trait-knowable-2.rs for more details. The idea is that while there may be an impl of the trait itself we don't know about, if we're able to prove that a super trait is definitely not implemented, then that impl would also never apply/not be well-formed. This approach is different from rust-lang#124532 as it allows tests/ui/coherence/super-traits/super-trait-knowable-3.rs to compile. The approach in rust-lang#124532 only elaborating the root obligations while this approach tries it for all unknowable trait goals. r? `@compiler-errors`
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters