Always make tuple elements a coercion site#147834
Always make tuple elements a coercion site#147834rust-bors[bot] merged 2 commits intorust-lang:mainfrom
Conversation
|
|
compiler/rustc_middle/src/ty/sty.rs
Outdated
|
|
||
| /// Returns a list of tuple type arguments, or `None` if `self` isn't a tuple. | ||
| #[inline] | ||
| pub fn tuple(self) -> Option<&'tcx List<Ty<'tcx>>> { |
There was a problem hiding this comment.
| pub fn tuple(self) -> Option<&'tcx List<Ty<'tcx>>> { | |
| pub fn opt_tuple_fields(self) -> Option<&'tcx List<Ty<'tcx>>> { |
seems like it does the same thing as tuple_fields it just doesnt panic
There was a problem hiding this comment.
That is indeed the case, is there a problem with that? In the code I wrote I found this a lot more convenient than checking the type first.
There was a problem hiding this comment.
no it's fine I just found the differences in the names doesn't really reflect the differences in behaviour
There was a problem hiding this comment.
If you have a better idea for the names I can rename them
There was a problem hiding this comment.
i suggested a different name already :P
There was a problem hiding this comment.
🤦🏻
I swear I sleep at night sometimes
|
@bors try @rust-timer queue should crater this as it is theoretically breaking, though I don't actually expect any breakage here 🤔 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Always make tuple elements a coercion site
|
When we stabilize the never type do we intend to change how NeverToAny coercions work? Will we continue unconditionally coercing |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (f77b5bc): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 1.4%, secondary -1.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -2.1%, secondary -3.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 473.373s -> 475.58s (0.47%) |
|
@craterbot check |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
I don't expect / haven't heard of any desire to make any changes with how we insert NeverToAny coercions. |
|
oh right i forgot to r+ this, r=me once rebased |
8fd56a2 to
3398ea2
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
@bors r=BoxyUwU |
|
📋 This PR cannot be approved because it currently has the following labels: |
|
@bors r=BoxyUwU The FCP was blocked for a while, everyone had enough time to raise concerns. Agreed with boxy that this doesn't have to wait any longer. |
|
⌛ Testing commit 3398ea2 with merge a138e0d... Workflow: https://github.com/rust-lang/rust/actions/runs/22864686275 |
Always make tuple elements a coercion site
Previously we only used `check_expr_coercible_to_type` if we had an expectation (using `check_expr_with_expectation(NoExpectation)` otherwise). Normally that'd be fine, because without an expectation we can't insert a coercion anyway. However, for the case of never-to-any coercion specifically, we _do_ insert it eagerly, so this prevents some code from compiling, for example:
```rust
((),) = (loop {},);
```
With this PR we are always using `check_expr_coercible_to_type` (using an infer var if there is no expectation), which allows slightly more code to compile.
Fixes #112856
r? BoxyUwU
Always make tuple elements a coercion site
Previously we only used `check_expr_coercible_to_type` if we had an expectation (using `check_expr_with_expectation(NoExpectation)` otherwise). Normally that'd be fine, because without an expectation we can't insert a coercion anyway. However, for the case of never-to-any coercion specifically, we _do_ insert it eagerly, so this prevents some code from compiling, for example:
```rust
((),) = (loop {},);
```
With this PR we are always using `check_expr_coercible_to_type` (using an infer var if there is no expectation), which allows slightly more code to compile.
Fixes rust-lang#112856
r? BoxyUwU
Always make tuple elements a coercion site
Previously we only used `check_expr_coercible_to_type` if we had an expectation (using `check_expr_with_expectation(NoExpectation)` otherwise). Normally that'd be fine, because without an expectation we can't insert a coercion anyway. However, for the case of never-to-any coercion specifically, we _do_ insert it eagerly, so this prevents some code from compiling, for example:
```rust
((),) = (loop {},);
```
With this PR we are always using `check_expr_coercible_to_type` (using an infer var if there is no expectation), which allows slightly more code to compile.
Fixes rust-lang#112856
r? BoxyUwU
Always make tuple elements a coercion site
Previously we only used `check_expr_coercible_to_type` if we had an expectation (using `check_expr_with_expectation(NoExpectation)` otherwise). Normally that'd be fine, because without an expectation we can't insert a coercion anyway. However, for the case of never-to-any coercion specifically, we _do_ insert it eagerly, so this prevents some code from compiling, for example:
```rust
((),) = (loop {},);
```
With this PR we are always using `check_expr_coercible_to_type` (using an infer var if there is no expectation), which allows slightly more code to compile.
Fixes rust-lang#112856
r? BoxyUwU
|
@bors yield |
|
Auto build was cancelled. Cancelled workflows: The next pull request likely to be tested is #153617. |
|
⌛ Testing commit 3398ea2 with merge 82e4d00... Workflow: https://github.com/rust-lang/rust/actions/runs/22865035946 |
Always make tuple elements a coercion site
Previously we only used `check_expr_coercible_to_type` if we had an expectation (using `check_expr_with_expectation(NoExpectation)` otherwise). Normally that'd be fine, because without an expectation we can't insert a coercion anyway. However, for the case of never-to-any coercion specifically, we _do_ insert it eagerly, so this prevents some code from compiling, for example:
```rust
((),) = (loop {},);
```
With this PR we are always using `check_expr_coercible_to_type` (using an infer var if there is no expectation), which allows slightly more code to compile.
Fixes #112856
r? BoxyUwU
|
@bors yield |
|
Auto build was cancelled. Cancelled workflows: The next pull request likely to be tested is #153617. |
Rollup merge of #147834 - WaffleLapkin:tuple-coerce, r=BoxyUwU Always make tuple elements a coercion site Previously we only used `check_expr_coercible_to_type` if we had an expectation (using `check_expr_with_expectation(NoExpectation)` otherwise). Normally that'd be fine, because without an expectation we can't insert a coercion anyway. However, for the case of never-to-any coercion specifically, we _do_ insert it eagerly, so this prevents some code from compiling, for example: ```rust ((),) = (loop {},); ``` With this PR we are always using `check_expr_coercible_to_type` (using an infer var if there is no expectation), which allows slightly more code to compile. Fixes #112856 r? BoxyUwU
…uwer Rollup of 4 pull requests Successful merges: - rust-lang/rust#147834 (Always make tuple elements a coercion site) - rust-lang/rust#150446 (miri/const eval: support `MaybeDangling`) - rust-lang/rust#153053 (stop marking `deref_patterns` as an incomplete feature) - rust-lang/rust#153398 (fix ICE in `const_c_variadic` when passing ZSTs)
View all comments
Previously we only used
check_expr_coercible_to_typeif we had an expectation (usingcheck_expr_with_expectation(NoExpectation)otherwise). Normally that'd be fine, because without an expectation we can't insert a coercion anyway. However, for the case of never-to-any coercion specifically, we do insert it eagerly, so this prevents some code from compiling, for example:With this PR we are always using
check_expr_coercible_to_type(using an infer var if there is no expectation), which allows slightly more code to compile.Fixes #112856
r? BoxyUwU