Skip to content
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

Rollup of 9 pull requests #129933

Closed
wants to merge 26 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

veera-sivarajan and others added 26 commits July 13, 2024 11:49
Inspired by discussion on
rust-lang#129486 this is intended to at
least document the current state of the world in a more public location
than throughout a series of issues.
The actual implementation remains in `rustc_mir_dataflow`, but this
commit moves the `MirPass` impl to `rustc_mir_transform` and changes it
to a `MirLint` (fixing a `FIXME` comment).

(I originally tried moving the full implementation from
`rustc_mir_dataflow` but I had some trait problems with `HasMoveData`
and `RustcPeekAt` and `MaybeLiveLocals`. This commit was much smaller
and simpler, but still will allow some follow-up cleanups.)
Because that's now the only crate that uses it.

Moving stuff out of `rustc_middle` is always welcome.

I chose to use `impl crate::MirPass`/`impl crate::MirLint` (with
explicit `crate::`) everywhere because that's the only mention of
`MirPass`/`MirLint` used in all of these files. (Prior to this change,
`MirPass` was mostly imported via `use rustc_middle::mir::*` items.)
They're now all just used within this crate.
Forgot this during the release process
…stebank

Suggest `impl Trait` for References to Bare Trait in Function Header

Fixes rust-lang#125139

This PR suggests `impl Trait` when `&Trait` is found as a function parameter type or return type. This makes use of existing diagnostics by adding `peel_refs()` when checking for type equality.

Additionaly, it makes a few other improvements:
1. Checks if functions inside impl blocks have bare trait in their headers.
2. Introduces a trait `NextLifetimeParamName` similar to the existing `NextTypeParamName` for suggesting a lifetime name. Also, abstracts out the common logic between the two trait impls.

### Related Issues
I ran into a bunch of related diagnostic issues but couldn't fix them within the scope of this PR. So, I have created the following issues:
1. [Misleading Suggestion when Returning a Reference to a Bare Trait from a Function](rust-lang#127689)
2. [Verbose Error When a Function Takes a Bare Trait as Parameter](rust-lang#127690)
3. [Incorrect Suggestion when Returning a Bare Trait from a Function](rust-lang#127691)

r​? ``@estebank`` since you implemented  rust-lang#119148
…bank

Don't Suggest Labeling `const` and `unsafe` Blocks

Fixes rust-lang#128604

Previously, both anonymous constant blocks (E.g. The labeled block
inside `['_'; 'block: { break 'block 1 + 2; }]`) and inline const
blocks (E.g. `const { ... }`) were considered to be the same
kind of blocks. This caused the compiler to incorrectly suggest
labeling both the blocks when only anonymous constant blocks can be
labeled.

This PR adds an other enum variant to `Context` so that both the
blocks can be handled appropriately.

Also, adds some doc comments and removes unnecessary `&mut` in a
couple of places.
…, r=compiler-errors

Non-exhaustive structs may be empty

This is a follow-up to a discrepancy noticed in rust-lang#122792: today, the following struct is considered inhabited (non-empty) outside its defining crate:
```rust
#[non_exhaustive]
pub struct UninhabitedStruct {
    pub never: !,
    // other fields
}
```

`#[non_exhaustive]` on a struct should mean that adding fields to it isn't a breaking change. There is no way that adding fields to this struct could make it non-empty since the `never` field must stay and is inconstructible. I suspect this was implemented this way due to confusion with `#[non_exhaustive]` enums, which indeed should be considered non-empty outside their defining crate.

I propose that we consider such a struct uninhabited (empty), just like it would be without the `#[non_exhaustive]` annotation.

Code that doesn't pass today and will pass after this:
```rust
// In a different crate
fn empty_match_on_empty_struct<T>(x: UninhabitedStruct) -> T {
    match x {}
}
```

This is not a breaking change.

r? `@compiler-errors`
…-on-wasm32-u-u, r=workingjubilee

Document the broken C ABI of `wasm32-unknown-unknown`

Inspired by discussion on
rust-lang#129486 this is intended to at least document the current state of the world in a more public location than throughout a series of issues.
Rename dump of coroutine by-move-body to be more consistent, fix ICE in dump_mir

First, we add a missing match for `DefKind::SyntheticCoroutineBody` in `dump_mir`. Fixes rust-lang#129703. The second commit (directly below) serves as a test.

Second, we reorder the `dump_mir` in `coroutine_by_move_body_def_id` to be *after* we adjust the body source, and change the disambiguator so it reads more like any other MIR body. This also serves as a test for the ICE, since we're dumping the MIR of a body with `DefKind::SyntheticCoroutineBody`.

Third, we change the parenting of the synthetic MIR body to have the *coroutine-closure* (i.e. async closure) as its parent, so we don't have long strings of `{closure#0}-{closure#0}-{closure#0}`.
do not attempt to prove unknowable goals

In case a goal is unknowable, we previously still checked all other possible ways to prove this goal, even though its final result is already guaranteed to be ambiguous. By ignoring all other candidates in that case we can avoid a lot of unnecessary work, fixing the performance regression in typenum found in rust-lang#121848.

This is already the behavior in the old solver. This could in theory cause future-compatability issues as considering fewer goals unknowable may end up causing performance regressions/hangs. I am quite confident that this will not be an issue.

r? `@compiler-errors`
…Pass, r=cjgillot

Move `SanityCheck` and `MirPass`

They are currently in `rustc_middle`. This PR moves them to `rustc_mir_transform`, which makes more sense.

r? `@cjgillot`
…tic, r=compiler-errors

rustc_driver_impl: remove some old dead logic

This got added in rust-lang@5013952, before `cfg(target_feature)` was stable. It should not be needed any more ever since `cfg(target_feature)` is stable.
…roalbini

include 1.80.1 release notes on master

Forgot this during the release process.
@rustbot 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. T-release Relevant to the release subteam, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative labels Sep 3, 2024
@rustbot rustbot added the rollup A PR which is a rollup label Sep 3, 2024
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=9

@bors
Copy link
Contributor

bors commented Sep 3, 2024

📌 Commit 67c3113 has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors 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 Sep 3, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 3, 2024
…iaskrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#127692 (Suggest `impl Trait` for References to Bare Trait in Function Header)
 - rust-lang#128701 (Don't Suggest Labeling `const` and `unsafe` Blocks )
 - rust-lang#128934 (Non-exhaustive structs may be empty)
 - rust-lang#129630 (Document the broken C ABI of `wasm32-unknown-unknown`)
 - rust-lang#129706 (Rename dump of coroutine by-move-body to be more consistent, fix ICE in dump_mir)
 - rust-lang#129896 (do not attempt to prove unknowable goals)
 - rust-lang#129926 (Move `SanityCheck` and `MirPass`)
 - rust-lang#129928 (rustc_driver_impl: remove some old dead logic)
 - rust-lang#129930 (include 1.80.1 release notes on master)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors
Copy link
Contributor

bors commented Sep 3, 2024

⌛ Testing commit 67c3113 with merge 93f7a9a...

@rust-log-analyzer
Copy link
Collaborator

The job test-various failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
test [mir-opt] tests/mir-opt/unusual_item_types.rs ... ok

failures:

---- [mir-opt] tests/mir-opt/async_closure_shims.rs stdout ----
1 // MIR for `main::{closure#0}::{closure#0}` 0 coroutine_closure_by_move
2 
- fn main::{closure#0}::{closure#0}(_1: {async closure@$DIR/async_closure_shims.rs:53:33: 53:52}, _2: i32) -> {async closure body@$DIR/async_closure_shims.rs:53:53: 56:10} {
-     let mut _0: {async closure body@$DIR/async_closure_shims.rs:53:53: 56:10};
+ fn main::{closure#0}::{closure#0}(_1: {async closure@$DIR/async_closure_shims.rs:55:33: 55:52}, _2: i32) -> {async closure body@$DIR/async_closure_shims.rs:55:53: 58:10} {
+     let mut _0: {async closure body@$DIR/async_closure_shims.rs:55:53: 58:10};
6     bb0: {
6     bb0: {
-         _0 = {coroutine@$DIR/async_closure_shims.rs:53:53: 56:10 (#0)} { a: move _2, b: move (_1.0: i32) };
+         _0 = {coroutine@$DIR/async_closure_shims.rs:55:53: 58:10 (#0)} { a: move _2, b: move (_1.0: i32) };
9     }
10 }

thread '[mir-opt] tests/mir-opt/async_closure_shims.rs' panicked at src/tools/compiletest/src/runtest.rs:4198:21:
thread '[mir-opt] tests/mir-opt/async_closure_shims.rs' panicked at src/tools/compiletest/src/runtest.rs:4198:21:
Actual MIR output differs from expected MIR output /checkout/tests/mir-opt/async_closure_shims.main-{closure#0}-{closure#0}.coroutine_closure_by_move.0.panic-abort.mir


failures:
    [mir-opt] tests/mir-opt/async_closure_shims.rs

@bors
Copy link
Contributor

bors commented Sep 3, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup 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. T-release Relevant to the release subteam, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative
Projects
None yet
Development

Successfully merging this pull request may close these issues.