-
Notifications
You must be signed in to change notification settings - Fork 12.2k
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
Allow constraining opaque types during subtyping in the trait system #125447
Conversation
This comment has been minimized.
This comment has been minimized.
This comment was marked as resolved.
This comment was marked as resolved.
This comment has been minimized.
This comment has been minimized.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
A minimized test: fn foo() -> impl Default {
let x = Default::default();
// add `Subtype(?x, ?y)` obligation
let y = x;
// Make a tuple `(?x, ?y)` and equate it with `(impl Default, u32)`.
// For us to try and prove a `Subtype(impl Default, u32)` obligation,
// we have to instantiate both `?x` and `?y` without any
// `select_where_possible` calls inbetween.
let tup = &mut (x, y);
let assign_tup = &mut (foo(), 1u32);
tup = assign_tup;
1u32
}
fn main() {} I think this change is clearly desirable, even if it did no go through an FCP. From what I can tell it also doesn't block any other work, as I want us to convert all places to use While I think it would have been fine to FCP merge this without first reverting this PR, we would only have 1 week to go through the FCP to make it in time for its stabilization. Given that we're missing some existing uncertainty wrt the impact of this change, please revert #123979 and remerge it after a types FCP. |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
@bors r+ |
…-errors Allow constraining opaque types during subtyping in the trait system Previous attempt: rust-lang#123979 Sometimes we don't immediately perform subtyping, but instead register a subtyping obligation and solve that obligation when its inference variables become resolved. Unlike immediate subtyping, we currently do not allow registering hidden types for opaque types. This PR also allows that.
UI tests might need rebless #126653 (comment) |
@bors r=compiler-errors |
Rollup of 6 pull requests Successful merges: - rust-lang#125447 (Allow constraining opaque types during subtyping in the trait system) - rust-lang#125766 (MCDC Coverage: instrument last boolean RHS operands from condition coverage) - rust-lang#125880 (Remove `src/tools/rust-demangler`) - rust-lang#126154 (StorageLive: refresh storage (instead of UB) when local is already live) - rust-lang#126572 (override user defined channel when using precompiled rustc) - rust-lang#126662 (Unconditionally warn on usage of `wasm32-wasi`) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#125447 - oli-obk:eq_opaque_pred, r=compiler-errors Allow constraining opaque types during subtyping in the trait system Previous attempt: rust-lang#123979 Sometimes we don't immediately perform subtyping, but instead register a subtyping obligation and solve that obligation when its inference variables become resolved. Unlike immediate subtyping, we currently do not allow registering hidden types for opaque types. This PR also allows that.
It's already merged, bors. What the hell? Edit: We currently have three full-build pending PRs, omg. |
@bors retry r- |
Previous attempt: #123979
Sometimes we don't immediately perform subtyping, but instead register a subtyping obligation and solve that obligation when its inference variables become resolved. Unlike immediate subtyping, we currently do not allow registering hidden types for opaque types. This PR also allows that.