-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Record the correct target type when coercing fn items/closures to pointers #129059
Merged
bors
merged 2 commits into
rust-lang:master
from
compiler-errors:subtyping-correct-type
Aug 14, 2024
Merged
Record the correct target type when coercing fn items/closures to pointers #129059
bors
merged 2 commits into
rust-lang:master
from
compiler-errors:subtyping-correct-type
Aug 14, 2024
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
WG-trait-system-refactor
The Rustc Trait System Refactor Initiative (-Znext-solver)
labels
Aug 13, 2024
lcnr
reviewed
Aug 13, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you also add a test which requires the sub
for closures, is case nothing hit that before?
compiler-errors
force-pushed
the
subtyping-correct-type
branch
from
August 13, 2024 20:21
3807970
to
6b164ea
Compare
compiler-errors
force-pushed
the
subtyping-correct-type
branch
from
August 13, 2024 20:23
6b164ea
to
5df13af
Compare
compiler-errors
changed the title
Record the correct target type when coercing fn items to pointers
Record the correct target type when coercing fn items/closures to pointers
Aug 13, 2024
@bors r+ rollup |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Aug 14, 2024
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Aug 14, 2024
…type, r=lcnr Record the correct target type when coercing fn items/closures to pointers Self-explanatory. We were previously not recording the *target* type of a coercion as the output of an adjustment. This should remedy that. We must also modify the function pointer casts in MIR typeck to use subtyping, since those broke since rust-lang#118247. r? lcnr
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 14, 2024
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#128828 (`-Znext-solver` caching) - rust-lang#128954 (Explicitly specify type parameter on FromResidual for Option and ControlFlow.) - rust-lang#129054 (Subtree update of `rust-analyzer`) - rust-lang#129059 (Record the correct target type when coercing fn items/closures to pointers) - rust-lang#129071 (Port `run-make/sysroot-crates-are-unstable` to rmake) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 14, 2024
Rollup of 6 pull requests Successful merges: - rust-lang#128570 (Stabilize `asm_const`) - rust-lang#128828 (`-Znext-solver` caching) - rust-lang#128954 (Explicitly specify type parameter on FromResidual for Option and ControlFlow.) - rust-lang#129059 (Record the correct target type when coercing fn items/closures to pointers) - rust-lang#129071 (Port `run-make/sysroot-crates-are-unstable` to rmake) - rust-lang#129088 (Make the rendered html doc for rustc better) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 14, 2024
Rollup merge of rust-lang#129059 - compiler-errors:subtyping-correct-type, r=lcnr Record the correct target type when coercing fn items/closures to pointers Self-explanatory. We were previously not recording the *target* type of a coercion as the output of an adjustment. This should remedy that. We must also modify the function pointer casts in MIR typeck to use subtyping, since those broke since rust-lang#118247. r? lcnr
What the heck -- this PR caused two regressions:
I'll look into both of them, and revert this if not. |
This was referenced Aug 20, 2024
Regression in clone impl of enum with variant that has a field with a bivariant substitution
#129286
Closed
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
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 pull request
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
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Aug 25, 2024
…, r=lcnr Use subtyping for `UnsafeFnPointer` coercion, too I overlooked this in rust-lang#129059, which changed MIR typechecking to use subtyping for other fn pointer coercions. Fixes rust-lang#129285
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Aug 25, 2024
…, r=lcnr Use subtyping for `UnsafeFnPointer` coercion, too I overlooked this in rust-lang#129059, which changed MIR typechecking to use subtyping for other fn pointer coercions. Fixes rust-lang#129285
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 26, 2024
Rollup merge of rust-lang#129288 - compiler-errors:unsafe-fn-coercion, r=lcnr Use subtyping for `UnsafeFnPointer` coercion, too I overlooked this in rust-lang#129059, which changed MIR typechecking to use subtyping for other fn pointer coercions. Fixes rust-lang#129285
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
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
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
WG-trait-system-refactor
The Rustc Trait System Refactor Initiative (-Znext-solver)
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Self-explanatory. We were previously not recording the target type of a coercion as the output of an adjustment. This should remedy that.
We must also modify the function pointer casts in MIR typeck to use subtyping, since those broke since #118247.
r? lcnr