-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Regression in clone impl of enum with variant that has a field with a bivariant substitution #129286
Labels
A-coercions
Area: implicit and explicit `expr as Type` coercions
A-variance
Area: Variance (https://doc.rust-lang.org/nomicon/subtyping.html)
C-bug
Category: This is a bug.
P-medium
Medium priority
regression-from-stable-to-nightly
Performance or correctness regression from stable to nightly.
T-types
Relevant to the types team, which will review and decide on the PR/issue.
Comments
Weirdly, this also only happens when the edit: yep, it has to do with the |
rust/compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs Lines 299 to 305 in 79611d9
lol we're not actually constraining the target of the coercion properly |
Minimal: trait Trait {
type Item;
}
struct Struct<A: Trait<Item = B>, B> {
pub field: A,
}
fn identity<T>(x: T) -> T {
x
}
fn test<A: Trait<Item = B>, B>(x: &Struct<A, B>) {
let x: &Struct<_, _> = identity(x);
} |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Aug 25, 2024
…g, r=<try> Use equality when relating formal and expected type in arg checking rust-lang#129059 uncovered an interesting issue in argument checking. When we check arguments, we create three sets of types: * Formals * Expected * Actuals The **actuals** are the types of the argument expressions themselves. The **formals** are the types from the signature that we're checking. The **expected** types are the formal types, but passed through `expected_inputs_for_expected_outputs`: https://github.com/rust-lang/rust/blob/a971212545766fdfe0dd68e5d968133f79944a19/compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs#L691-L725 This method attempts to constrain the formal inputs by relating the [expectation](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_typeck/expectation/enum.Expectation.html) of the call expression and the formal output. When we check an argument, we get the expression's actual type, and then we first attempt to coerce it to the expected type: https://github.com/rust-lang/rust/blob/a971212545766fdfe0dd68e5d968133f79944a19/compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs#L280-L293 Then we subtype the expected type and the formal type: https://github.com/rust-lang/rust/blob/a971212545766fdfe0dd68e5d968133f79944a19/compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs#L299-L305 However, since we are now recording the right coercion target (since rust-lang#129059), we now end up recording the expected type to the typeck results, rather than the actual. Since that expected type was [fudged](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/struct.InferCtxt.html#method.fudge_inference_if_ok), it has fresh variables. And since the expected type is only subtyped against the formal type, if that expected type has a bivariant parameter, it will likely remain unconstrained since `Covariant * Bivariant = Bivariant` according to [xform](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.Variance.html#method.xform). This leads to an unconstrained type variable in writeback. AFAICT, there's no reason for us to be using subtyping here, though. The expected output is already related to the expectation by subtyping: https://github.com/rust-lang/rust/blob/a971212545766fdfe0dd68e5d968133f79944a19/compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs#L713 So the formals don't need "another" indirection of subtyping in the argument checking... So I've changed it to use equality here. We could alternatively fix this by requiring WF for all the expected types to constrain their bivariant parameters, but this seems a bit overkill. Fixes rust-lang#129286
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Aug 25, 2024
…g, r=<try> Use equality when relating formal and expected type in arg checking rust-lang#129059 uncovered an interesting issue in argument checking. When we check arguments, we create three sets of types: * Formals * Expected * Actuals The **actuals** are the types of the argument expressions themselves. The **formals** are the types from the signature that we're checking. The **expected** types are the formal types, but passed through `expected_inputs_for_expected_outputs`: https://github.com/rust-lang/rust/blob/a971212545766fdfe0dd68e5d968133f79944a19/compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs#L691-L725 This method attempts to constrain the formal inputs by relating the [expectation](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_typeck/expectation/enum.Expectation.html) of the call expression and the formal output. When we check an argument, we get the expression's actual type, and then we first attempt to coerce it to the expected type: https://github.com/rust-lang/rust/blob/a971212545766fdfe0dd68e5d968133f79944a19/compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs#L280-L293 Then we subtype the expected type and the formal type: https://github.com/rust-lang/rust/blob/a971212545766fdfe0dd68e5d968133f79944a19/compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs#L299-L305 However, since we are now recording the right coercion target (since rust-lang#129059), we now end up recording the expected type to the typeck results, rather than the actual. Since that expected type was [fudged](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/struct.InferCtxt.html#method.fudge_inference_if_ok), it has fresh variables. And since the expected type is only subtyped against the formal type, if that expected type has a bivariant parameter, it will likely remain unconstrained since `Covariant * Bivariant = Bivariant` according to [xform](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.Variance.html#method.xform). This leads to an unconstrained type variable in writeback. AFAICT, there's no reason for us to be using subtyping here, though. The expected output is already related to the expectation by subtyping: https://github.com/rust-lang/rust/blob/a971212545766fdfe0dd68e5d968133f79944a19/compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs#L713 So the formals don't need "another" indirection of subtyping in the argument checking... So I've changed it to use equality here. We could alternatively fix this by requiring WF for all the expected types to constrain their bivariant parameters, but this seems a bit overkill. Fixes rust-lang#129286
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Sep 2, 2024
…g, r=lcnr Use equality when relating formal and expected type in arg checking rust-lang#129059 uncovered an interesting issue in argument checking. When we check arguments, we create three sets of types: * Formals * Expected * Actuals The **actuals** are the types of the argument expressions themselves. The **formals** are the types from the signature that we're checking. The **expected** types are the formal types, but passed through `expected_inputs_for_expected_outputs`: https://github.com/rust-lang/rust/blob/a971212545766fdfe0dd68e5d968133f79944a19/compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs#L691-L725 This method attempts to constrain the formal inputs by relating the [expectation](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_typeck/expectation/enum.Expectation.html) of the call expression and the formal output. When we check an argument, we get the expression's actual type, and then we first attempt to coerce it to the expected type: https://github.com/rust-lang/rust/blob/a971212545766fdfe0dd68e5d968133f79944a19/compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs#L280-L293 Then we subtype the expected type and the formal type: https://github.com/rust-lang/rust/blob/a971212545766fdfe0dd68e5d968133f79944a19/compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs#L299-L305 However, since we are now recording the right coercion target (since rust-lang#129059), we now end up recording the expected type to the typeck results, rather than the actual. Since that expected type was [fudged](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/struct.InferCtxt.html#method.fudge_inference_if_ok), it has fresh variables. And since the expected type is only subtyped against the formal type, if that expected type has a bivariant parameter, it will likely remain unconstrained since `Covariant * Bivariant = Bivariant` according to [xform](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.Variance.html#method.xform). This leads to an unconstrained type variable in writeback. AFAICT, there's no reason for us to be using subtyping here, though. The expected output is already related to the expectation by subtyping: https://github.com/rust-lang/rust/blob/a971212545766fdfe0dd68e5d968133f79944a19/compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs#L713 So the formals don't need "another" indirection of subtyping in the argument checking... So I've changed it to use equality here. We could alternatively fix this by requiring WF for all the expected types to constrain their bivariant parameters, but this seems a bit overkill. Fixes rust-lang#129286
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Labels
A-coercions
Area: implicit and explicit `expr as Type` coercions
A-variance
Area: Variance (https://doc.rust-lang.org/nomicon/subtyping.html)
C-bug
Category: This is a bug.
P-medium
Medium priority
regression-from-stable-to-nightly
Performance or correctness regression from stable to nightly.
T-types
Relevant to the types team, which will review and decide on the PR/issue.
I tried this code:
I expected it to work.
Instead, this happened:
I regressed this in #129059. I have no idea yet why it's happening! This also could be minimized further, I think.
The text was updated successfully, but these errors were encountered: