-
Notifications
You must be signed in to change notification settings - Fork 0
rocket regression: rigid alias don't require trait to hold #177
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
Comments
This comment has been minimized.
This comment has been minimized.
Has to do with the leak check and higher ranked trait bounds b/c of coroutine witness erasure.
Proving the coroutine is Checking this goal goes through assemble_object_bound_candidates -> probe_and_consider_object_bound_candidate, which equates the self type with itself. That emits an alias-relate goal Since all we know is that |
The reason this doesn't fail in the old solver is b/c we don't check that rigid projections implement their trait goal, lol. |
I'm curious to know exactly what the fallout of this is in the old solver: rust-lang/rust#139763 |
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
https://crater-reports.s3.amazonaws.com/pr-133502-1/try%23fa8e241660363f48d64b66b05eea58c93ab828fb/reg/rocket-0.5.1/log.txt
Minimized:
The text was updated successfully, but these errors were encountered: