Skip to content

Rollup of 12 pull requests - #165281

Closed
JonathanBrouwer wants to merge 46 commits into
rust-lang:mainfrom
JonathanBrouwer:rollup-2Wffsgt
Closed

JonathanBrouwer wants to merge 46 commits into
rust-lang:mainfrom
JonathanBrouwer:rollup-2Wffsgt

Conversation

@JonathanBrouwer

Copy link
Copy Markdown
Member

Successful merges:

r? @ghost

Create a similar rollup

maxdexh and others added 30 commits October 15, 2026 20:07
This lint is similar to the existing `let_underscore_lock` lint,
but applies to `DropGuard` instead of `MutexGuard` and similar types.
This becomes particularly confusing when a type parameter has a default.

```
  --> $DIR/default-type-parameter.rs:8:17
   |
LL |     fn foo() -> u32 { 0 }
   |                 ^^^ expected `()`, found `u32`
   |
note: type in trait
  --> $DIR/default-type-parameter.rs:2:17
   |
LL |     fn foo() -> T;
   |                 ^
   = note: expected signature `fn() -> ()`
              found signature `fn() -> u32`
note: expected to match this type parameter
  --> $DIR/default-type-parameter.rs:1:13
   |
LL | trait Trait<T = ()> {
   |             ^^^^^^
help: change the output type to match the trait
   |
LL -     fn foo() -> u32 { 0 }
LL +     fn foo() -> () { 0 }
```
…the trait

```
error[E0053]: method `foo` has an incompatible type for trait
  --> $DIR/async-example-desugared-boxed-in-trait.rs:11:28
   |
LL | impl MyTrait for i32 {
LL |     async fn foo(&self) -> i32 {
   |                            ^^^ expected `Pin<Box<dyn Future<Output = i32>>>`, found future
   |
note: type in trait
  --> $DIR/async-example-desugared-boxed-in-trait.rs:7:22
   |
LL | trait MyTrait {
LL |     fn foo(&self) -> Pin<Box<dyn Future<Output = i32> + '_>>;
   |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   = note: expected signature `fn(&_) -> Pin<Box<dyn Future<Output = i32>>>`
              found signature `fn(&_) -> impl Future<Output = i32>`
```
…type in trait" note

```
error[E0053]: method `foo` has an incompatible type for trait
  --> $DIR/default-type-parameter.rs:8:17
   |
LL | impl Trait for S {
LL |     fn foo() -> u32 { 0 }
   |                 ^^^ expected `()`, found `u32`
   |
note: type in trait
  --> $DIR/default-type-parameter.rs:2:17
   |
LL | trait Trait<T = ()> {
   |             ------ expected to match the default of type parameter `T`
LL |     fn foo() -> T;
   |                 ^
   = note: expected signature `fn() -> ()`
              found signature `fn() -> u32`
help: change the output type to match the trait
   |
LL -     fn foo() -> u32 { 0 }
LL +     fn foo() -> () { 0 }
   |
```
Verbose suggestions are much easier to read for people, at the cost of marginal additional vertical real estate in some cases.

```
error[E0423]: cannot find value `SomeStruct` in crate `remapped_dep`
  --> $DIR/remap-path-prefix-reverse.rs:15:27
   |
LL |     let _ = remapped_dep::SomeStruct;
   |                           ^^^^^^^^^^
   |
  ::: remapped-aux/remapped_dep.rs:4:1
   |
LL | pub struct SomeStruct {} // This line should be show as part of the error.
   | --------------------- `remapped_dep::SomeStruct` defined here
   |
   = note: a struct named `remapped_dep::SomeStruct` exists in another namespace
help: use struct literal syntax instead
   |
LL |     let _ = remapped_dep::SomeStruct {};
   |                                      ++
```
instead of
```
error[E0423]: cannot find value `SomeStruct` in crate `remapped_dep`
  --> $DIR/remap-path-prefix-reverse.rs:15:27
   |
LL |     let _ = remapped_dep::SomeStruct;
   |             --------------^^^^^^^^^^
   |             |
   |             help: use struct literal syntax instead: `remapped_dep::SomeStruct {}`
   |
  ::: remapped-aux/remapped_dep.rs:4:1
   |
LL | pub struct SomeStruct {} // This line should be show as part of the error.
   | --------------------- `remapped_dep::SomeStruct` defined here
   |
   = note: a struct named `remapped_dep::SomeStruct` exists in another namespace
```
When encountering a tuple struct that can't be constructed because of private fields, do not suggest local binding typo, as the only valid case would be a local closure but during resolve we can't confirm that is the case.
When used, this option creates a subheading within the sidebar
“Crates” list for this crate and all crates which pass the same value.
These headings are displayed in alphabetical order; crates without the
option, or with it set to the empty string, always appear first.

The intended use of this option is to allow Cargo to automatically
separate a workspace’s crate list into the workspace’s own crates
and their external dependencies. Authors could also use RUSTDOCFLAGS
or other means to create custom headings for their documentation builds.
…rd, r=petrochenkov

Add `let_underscore_drop_guard` lint.

This lint is similar to the existing [`let_underscore_lock`](https://doc.rust-lang.org/rustc/lints/listing/deny-by-default.html#let-underscore-lock) lint, but applies to `DropGuard` instead of `MutexGuard` and similar types. It is deny-by-default, like `let_underscore_lock`. (Note that the related `let_underscore_drop` lint is allow-by-default.)

Relevant discussion: [#t-libs > Linting &rust-lang#96;let _ = DropGuard::new(....);&rust-lang#96;](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Linting.20.60let.20_.20.3D.20DropGuard.3A.3Anew.28.2E.2E.2E.2E.29.3B.60/with/631977543)

Note that `DropGuard` is a newly stabilized type, currently in 1.100 beta, and will be on the 1.100 stable release on November 12.

Tracking issue for `DropGuard`: rust-lang#144426
Provide more context when an expected type was a type parameter

This becomes particularly confusing when a type parameter has a default.

```
error[E0053]: method `foo` has an incompatible type for trait
  --> $DIR/default-type-parameter.rs:8:17
   |
LL | impl Trait for S {
LL |     fn foo() -> u32 { 0 }
   |                 ^^^ expected `()`, found `u32`
   |
note: type in trait
  --> $DIR/default-type-parameter.rs:2:17
   |
LL | trait Trait<T = ()> {
   |             ------ expected to match the default of type parameter `T`
LL |     fn foo() -> T;
   |                 ^
   = note: expected signature `fn() -> ()`
              found signature `fn() -> u32`
help: change the output type to match the trait
   |
LL -     fn foo() -> u32 { 0 }
LL +     fn foo() -> () { 0 }
   |
```
Fix rust-lang#67991.
Refactor box downcasting methods

We are doing this too often:
```rust
let (raw, alloc) = Box::into_raw_with_allocator(this);
Box::from_raw_in(raw.cast(), alloc)
```
So I factored it out into its own function.

Also the downcasting methods for `dyn Any/Error + AutoTraits` are all doing the same thing, and can be implemented using the same generic function.

The code transmuting `Box<dyn Error>` back to `Box<dyn Error + AutoTraits>` was also super dubious for no good reason (other than convenience)
…65, r=joboet

Improve mem::take wording

Closes rust-lang#165065

Updated to use “switch” instead of “replace”.
[small] Tweak suggestions in struct literal resolve errors

When encountering a tuple struct that can't be constructed because of private fields, do not suggest local binding typo, as the only valid case would be a local closure but during resolve we can't confirm that is the case. Fix rust-lang#66067.

Make incorrect struct literal syntax suggestion verbose. Verbose suggestions are much easier to read for people, at the cost of marginal additional vertical real estate in some cases.

```
error[E0423]: cannot find value `SomeStruct` in crate `remapped_dep`
  --> $DIR/remap-path-prefix-reverse.rs:15:27
   |
LL |     let _ = remapped_dep::SomeStruct;
   |                           ^^^^^^^^^^
   |
  ::: remapped-aux/remapped_dep.rs:4:1
   |
LL | pub struct SomeStruct {} // This line should be show as part of the error.
   | --------------------- `remapped_dep::SomeStruct` defined here
   |
   = note: a struct named `remapped_dep::SomeStruct` exists in another namespace
help: use struct literal syntax instead
   |
LL |     let _ = remapped_dep::SomeStruct {};
   |                                      ++
```
instead of
```
error[E0423]: cannot find value `SomeStruct` in crate `remapped_dep`
  --> $DIR/remap-path-prefix-reverse.rs:15:27
   |
LL |     let _ = remapped_dep::SomeStruct;
   |             --------------^^^^^^^^^^
   |             |
   |             help: use struct literal syntax instead: `remapped_dep::SomeStruct {}`
   |
  ::: remapped-aux/remapped_dep.rs:4:1
   |
LL | pub struct SomeStruct {} // This line should be show as part of the error.
   | --------------------- `remapped_dep::SomeStruct` defined here
   |
   = note: a struct named `remapped_dep::SomeStruct` exists in another namespace
```
… r=workingjubilee

Replace `AbiAlign` with `Align` in function returns

This PR replaces all uses of `AbiAlign` in function returns with `Align`. Each commit replaces it as the result of a individual/pair of functions, for ease of reviewing (the `pointer_align` commit is the largest). After this the only use of `AbiAlign` left will be `align` in `LayoutData`.

r? @workingjubilee
…again, r=Kobzol

Bless mir-opt tests again, again

r? @Kobzol
Revert recent changes to async_drop

Reverts rust-lang#164987
Fixes rust-lang#165263 (Note that some big crates are currently broken from this on nightly)
Unfixes rust-lang#142155, rust-lang#164901
(A bit of context on [zulip](https://rust-lang.zulipchat.com/#narrow/channel/245100-t-compiler.2Fprioritization.2Falerts/topic/.23165263.20Regression.3A.20.22cycle.20detected.20when.20computing.20when.20.60T.60.E2.80.A6/with/636612201))

Also added a regression test.

r? oli-obk (reviewer of the reverted PR)
If you think there is a way to fix this in a timely manner without reverting the entire PR, feel free to close.
…ls, r=Kivooeo

Fix FCW issue template labels

Previously, creating an issue with this template would produce an issue with no labels.
@rust-bors rust-bors Bot added the rollup A PR which is a rollup label Nov 1, 2026
@rustbot rustbot added A-CI Area: Our Github Actions CI A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-run-make Area: port run-make Makefiles to rmake.rs A-rustdoc-js Area: Rustdoc's JS front-end A-testsuite Area: The testsuite used to check the correctness of rustc 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-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. labels Nov 1, 2026
@JonathanBrouwer

Copy link
Copy Markdown
Member Author

@bors r+ p=5 force

@rust-bors

rust-bors Bot commented Nov 1, 2026

Copy link
Copy Markdown
Contributor

📌 Commit c2a64e9 has been approved by JonathanBrouwer

It is now in the queue for this repository.

@rust-bors rust-bors Bot 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 Nov 1, 2026
@rust-bors rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 1, 2026
@rust-bors

rust-bors Bot commented Nov 1, 2026

Copy link
Copy Markdown
Contributor

This pull request was unapproved due to being closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-CI Area: Our Github Actions CI A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-run-make Area: port run-make Makefiles to rmake.rs A-rustdoc-js Area: Rustdoc's JS front-end A-testsuite Area: The testsuite used to check the correctness of rustc rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output.

Projects

None yet

Development

Successfully merging this pull request may close these issues.