-
Notifications
You must be signed in to change notification settings - Fork 13.3k
[Experiment] Check that corresponding trait goal holds when projection is rigid #139763
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
[Experiment] Check that corresponding trait goal holds when projection is rigid #139763
Conversation
@bors try |
…lver, r=<try> [Experiment] Check that corresponding trait goal holds when projection is rigid r? `@ghost`
The job Click to see the possible cause of the failure (guessed by this bot)
|
☀️ Try build successful - checks-actions |
@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
|
As expected, 1 quadrillion regressions. These will almost certainly need to be fixed in the new solver. |
Don't require rigid alias's trait to hold See test for write-up. TL;DR is that we don't need the trait bound to hold, since we enforce it during WF. I think this is preferable to introducing (if we even could do so) a more specific hack around coroutine interiors, higher ranked types, etc, since this is just a manifestation of more pervasive issues w/ lifetime erasure in coroutines. This just doesn't manifest in the old solver b/c it doesn't try to prove `T: Trait` holds when rigidly projecting `<T as Trait>::Assoc`. It's pretty clear that this affects quite a few traits (rust-lang#139763), so I think this needs fixing. r? lcnr Fixes rust-lang/trait-system-refactor-initiative#177
Rollup merge of rust-lang#139828 - compiler-errors:rigid-trait, r=lcnr Don't require rigid alias's trait to hold See test for write-up. TL;DR is that we don't need the trait bound to hold, since we enforce it during WF. I think this is preferable to introducing (if we even could do so) a more specific hack around coroutine interiors, higher ranked types, etc, since this is just a manifestation of more pervasive issues w/ lifetime erasure in coroutines. This just doesn't manifest in the old solver b/c it doesn't try to prove `T: Trait` holds when rigidly projecting `<T as Trait>::Assoc`. It's pretty clear that this affects quite a few traits (rust-lang#139763), so I think this needs fixing. r? lcnr Fixes rust-lang/trait-system-refactor-initiative#177
Don't require rigid alias's trait to hold See test for write-up. TL;DR is that we don't need the trait bound to hold, since we enforce it during WF. I think this is preferable to introducing (if we even could do so) a more specific hack around coroutine interiors, higher ranked types, etc, since this is just a manifestation of more pervasive issues w/ lifetime erasure in coroutines. This just doesn't manifest in the old solver b/c it doesn't try to prove `T: Trait` holds when rigidly projecting `<T as Trait>::Assoc`. It's pretty clear that this affects quite a few traits (rust-lang/rust#139763), so I think this needs fixing. r? lcnr Fixes rust-lang/trait-system-refactor-initiative#177
r? @ghost