Require coherence of supertrait associated item bounds for dyn-compability - #158915
theemathas wants to merge 2 commits into
Conversation
|
I'm unsure of what to do with the now-failing tests. I'm also rather unsure of my code in general. Please be careful with the review to make sure I didn't do anything stupid. Thank you. |
4d67fa1 to
256670e
Compare
|
r? types |
|
after that, we should do a crater run 😁 |
|
@rustbot author |
|
Reminder, once the PR becomes ready for a review, use |
This comment has been minimized.
This comment has been minimized.
256670e to
4adf718
Compare
This comment has been minimized.
This comment has been minimized.
4adf718 to
97592bc
Compare
|
I decided to ask an LLM for assistance with understanding how the trait solver API works, and with double-checking my code for any glaring issues. I still wrote all code manually. In particular, the LLM did the following:
I claim full responsibility of all code in this PR. |
| // Now that we've constrained the two projections to be on the same thing, | ||
| // we check whether the two terms are necessarily equal to each other. | ||
| // If they are, then the two projections are coherent. | ||
| plug_infer_with_placeholders(&infcx, ty::UniverseIndex::ROOT, (proj_1, proj_2)); | ||
| let ocx = ObligationCtxt::new(&infcx); | ||
| ocx.eq(&ObligationCause::dummy(), param_env, proj_1.term, proj_2.term).is_ok() | ||
| && ocx.evaluate_obligations_error_on_ambiguity().no_errors() | ||
| && ocx.resolve_regions(CRATE_DEF_ID, param_env, []).is_empty() | ||
| } |
There was a problem hiding this comment.
The LLM, in reviewing my code, told me that I have to instantiate the param_env with trait_args here. However, I should not do this instantiation in the can_equate_generics computation. Is the LLM right here? I don't understand at all what this does.
There was a problem hiding this comment.
This test is currently the only pre-existing test that this PR breaks. What should be done about this test?
|
Is this PR ready for a crater run? @rustbot ready |
97592bc to
8546c21
Compare
|
I just realized that the current implementation has a weird consequence: It is possible for a dyn-compatible trait to be a subtrait of a dyn-incompatible trait. For example: trait Super<T> {
type Assoc;
}
trait Sub<T, U>: Super<T, Assoc = i32> + Super<U, Assoc = i64> {}
trait Sub2: Sub<i32, i64> {}In the above code, |
|
Finished benchmarking commit (e3607d5): comparison URL. Overall result: no relevant changes - no action neededBenchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up. @rustbot label: -S-waiting-on-perf -perf-regression Instruction countThis perf run didn't have relevant results for this metric. Max RSS (memory usage)Results (primary 1.9%, secondary 4.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -1.6%, secondary 2.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 478.991s -> 480.616s (0.34%) |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
Pushed a fix. I'll finagle with the commit splitting later. Let's rerun crater. @bors try |
This comment has been minimized.
This comment has been minimized.
Require coherence of supertrait associated item bounds for dyn-compability
|
@craterbot check |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
Footnotes
|
This comment has been minimized.
This comment has been minimized.
|
Crater is clean. |
5a1c765 to
2c711a8
Compare
This comment has been minimized.
This comment has been minimized.
…ics. See rust-lang#154662 These tests will be fixed in a subsequent commit.
…ility Fixes rust-lang#154662 In a `dyn` type, if multiple bounds are specified via supertraits for the same associated item, then we previously accepted them if the relevant trait's generics are different, even if the bounds conflict. This was unsound, since those generics could end up being instantiated with identical concrete types, causing the `dyn` type to have two different "values" for the same bound. Thus, if a trait has multiple supertrait bounds for the same associated item, we check whether those bounds are coherent, similarly to how we check for overlap between impls (i.e., we check if the generics could be instantiated to be the same while the "values" of the bounds are different). If the bounds are incoherent, then we consider the trait to be dyn-incompatible.
2c711a8 to
20cb1f3
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
Squashed into 2 commits, and rebased. Ready for review, and hopefully ready for FCP. |
View all comments
This PR is an alternative to #157710. However, unlike that PR, this PR does not address #150936.
Fixes #154662
In a
dyntype, if multiple bounds are specified via supertraits for the same associated item, then we previously accepted them if the relevant trait's generics are different, even if the bounds conflict.This was unsound, since those generics could end up being instantiated with identical concrete types, causing the
dyntype to have two different "values" for the same bound.Thus, if a trait has multiple supertrait bounds for the same associated item, we check whether those bounds are coherent, similarly to how we check for overlap between impls (i.e., we check if the generics could be instantiated to be the same while the "values" of the bounds are different). If the bounds are incoherent, then we consider the trait to be dyn-incompatible.
r? @fmease