Rollup of 12 pull requests #149796

Zalathar · 2025-12-09T01:37:52Z

Successful merges:

std: Use more unix.rs code on WASI targets #147572 (std: Use more unix.rs code on WASI targets)
Correctly provide suggestions when encountering async fn with a dyn Trait return type #148491 ( Correctly provide suggestions when encountering async fn with a dyn Trait return type)
Emit check-cfg lints during attribute parsing rather than evaluation #149215 (Emit check-cfg lints during attribute parsing rather than evaluation)
Add release notes for 1.92.0 #149652 (Add release notes for 1.92.0)
rustdoc book: mention inner doc attribute #149720 (rustdoc book: mention inner doc attribute)
lint: emit proper diagnostic for unsafe binders in improper_ctypes instead of ICE #149730 (lint: emit proper diagnostic for unsafe binders in improper_ctypes instead of ICE)
Retire opt_str2 from compiletest cli parsing #149754 (Retire opt_str2 from compiletest cli parsing)
bootstrap: Use a CompiletestMode enum instead of bare strings #149755 (bootstrap: Use a CompiletestMode enum instead of bare strings)
Add inline attribute to generated delegation function if needed #149763 (Add inline attribute to generated delegation function if needed)
test: Add a test for 146133 #149772 (test: Add a test for 146133)
Fix typo "an" → "and" #149779 (Fix typo "an" → "and")
Remove [no-mentions] handler in the triagebot config #149782 (Remove [no-mentions] handler in the triagebot config)

r? @ghost
@rustbot modify labels: rollup

…n#149215

Instead of allowing them to be missing and using some placeholder "(none)" value instead.

Instead of possibly falling back to "(none)" when they are not specified.

We either have the value of a flag specified, or we don't. Use `Option<...>` to represent that -- don't invent a new "(none)" sentinel value...

This derive was an artifact of test-only method `Cache::all` wanting to automatically sort its output to hide HashMap iteration order. We can achieve an equivalent result by requiring the caller to provide a projection function that returns results that _are_ sortable.

Replaced _binder with _

Even if a crate is marked as #![no_builtins], we can still generate bitcode for rlib, but we cannot emit bitcode to the linker in rustc's LTO.

This commit is a large change to the implementation of filesystem and other system-related operations on WASI targets. Previously the standard library explicitly used the `wasi` crate at the 0.11.x version track which means that it used WASIp1 APIs directly. This meant that `std` was hard-coded to use WASIp1 syscalls and there was no separate implementation for the WASIp{2,3} targets, for example. The high-level goal of this commit is to decouple this interaction and avoid the use of the `wasi` crate on the WASIp2 target. Historically when WASIp1 was originally added to Rust the wasi-libc library was in a much different position than it is today. Nowadays Rust already depends on wasi-libc on WASI targets for things like memory allocation and environment variable management. As a libc library it also has all the functions necessary to implement all filesystem operations Rust wants. Recently wasi-libc additionally was updated to use WASIp2 APIs directly on the `wasm32-wasip2` target instead of using `wasm32-wasip1` APIs. This commit is leveraging this work by enabling Rust to completely sever the dependence on WASIp1 APIs when compiling for `wasm32-wasip2`. This is also intended to make it easier to migrate to `wasm32-wasip3` internally in the future where now only libc need be updated and Rust doesn't need to explicitly change as well. The overall premise of this commit is that there's no need for WASI-specific implementation modules throughout the standard library. Instead the libc-style bindings already implemented for Unix-like targets are sufficient. This means that Rust will now be using libc-style interfaces to interact with the filesystem, for example, and wasi-libc is the one responsible for translating these POSIX-ish functions into WASIp{1,2} calls. Concrete changes here are: * `std` for `wasm32-wasip2` no longer depends on `wasi 0.11.x` * The implementation of `std::os::wasi::fs`, which was previously unstable and still is, now has portions gated to only work on the WASIp1 target which use the `wasi` crate directly. Traits have been trimmed down in some cases, updated in others, or now present a different API on WASIp1 and WASIp2. It's expected this'll get further cleanup in the future. * The `std::sys::fd::wasi` module is deleted and `unix` is used instead. * The `std::sys::fs::wasi` module is deleted and `unix` is used instead. * The `std::sys::io::io_slice::wasi` module is deleted and `unix` is used instead. * The `std::sys::pal::{wasip1,wasip2}` modules are now merged together as their difference is much smaller than before. * The `std::sys::pal::wasi::time` is deleted and the `unix` variant is used directly instead. * The `std::sys::stdio::wasip{1,2}` modules are deleted and the `unix` variant is used instead. * The `std::sys::thread::wasip{1,2}` modules are deleted and the `unix` variant is used instead. Overall Rust's libstd is effectively more tightly bound to libc when compiled to WASI targets. This is intended to mirror how it's expected all other languages will also bind to WASI. This additionally has the nice goal of drastically reducing the WASI-specific maintenance burden in libstd (in theory) and the only real changes required here are extra definitions being added to `libc` (done in separate PRs). This might be required for more symbols in the future but for now everything should be mostly complete.

https://github.blog/changelog/2025-11-07-removing-notifications-for-mentions-in-commit-messages/

…uggestion

``` error[E0277]: the size for values of type `(dyn Debug + 'static)` cannot be known at compilation time --> $DIR/dyn-trait-type-alias-return-type.rs:4:11 | LL | fn f() -> T { loop {} } | ^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `(dyn Debug + 'static)` note: this type alias is unsized --> $DIR/dyn-trait-type-alias-return-type.rs:1:1 | LL | type T = dyn core::fmt::Debug; | ^^^^^^ = note: the return type of a function must have a statically known size ```

…-Simulacrum std: Use more `unix.rs` code on WASI targets This commit is a large change to the implementation of filesystem and other system-related operations on WASI targets. Previously the standard library explicitly used the `wasi` crate at the 0.11.x version track which means that it used WASIp1 APIs directly. This meant that `std` was hard-coded to use WASIp1 syscalls and there was no separate implementation for the WASIp{2,3} targets, for example. The high-level goal of this commit is to decouple this interaction and avoid the use of the `wasi` crate on the WASIp2 target. Historically when WASIp1 was originally added to Rust the wasi-libc library was in a much different position than it is today. Nowadays Rust already depends on wasi-libc on WASI targets for things like memory allocation and environment variable management. As a libc library it also has all the functions necessary to implement all filesystem operations Rust wants. Recently wasi-libc additionally was updated to use WASIp2 APIs directly on the `wasm32-wasip2` target instead of using `wasm32-wasip1` APIs. This commit is leveraging this work by enabling Rust to completely sever the dependence on WASIp1 APIs when compiling for `wasm32-wasip2`. This is also intended to make it easier to migrate to `wasm32-wasip3` internally in the future where now only libc need be updated and Rust doesn't need to explicitly change as well. The overall premise of this commit is that there's no need for WASI-specific implementation modules throughout the standard library. Instead the libc-style bindings already implemented for Unix-like targets are sufficient. This means that Rust will now be using libc-style interfaces to interact with the filesystem, for example, and wasi-libc is the one responsible for translating these POSIX-ish functions into WASIp{1,2} calls. Concrete changes here are: * `std` for `wasm32-wasip2` no longer depends on `wasi 0.11.x` * The implementation of `std::os::wasi::fs`, which was previously unstable and still is, now has portions gated to only work on the WASIp1 target which use the `wasi` crate directly. Traits have been trimmed down in some cases, updated in others, or now present a different API on WASIp1 and WASIp2. It's expected this'll get further cleanup in the future. * The `std::sys::fd::wasi` module is deleted and `unix` is used instead. * The `std::sys::fs::wasi` module is deleted and `unix` is used instead. * The `std::sys::io::io_slice::wasi` module is deleted and `unix` is used instead. * The `std::sys::pal::{wasip1,wasip2}` modules are now merged together as their difference is much smaller than before. * The `std::sys::pal::wasi::time` is deleted and the `unix` variant is used directly instead. * The `std::sys::stdio::wasip{1,2}` modules are deleted and the `unix` variant is used instead. * The `std::sys::thread::wasip{1,2}` modules are deleted and the `unix` variant is used instead. Overall Rust's libstd is effectively more tightly bound to libc when compiled to WASI targets. This is intended to mirror how it's expected all other languages will also bind to WASI. This additionally has the nice goal of drastically reducing the WASI-specific maintenance burden in libstd (in theory) and the only real changes required here are extra definitions being added to `libc` (done in separate PRs). This might be required for more symbols in the future but for now everything should be mostly complete.

Correctly provide suggestions when encountering `async fn` with a `dyn Trait` return type Point at return type of `async fn`s instead of their def `Span`. Correctly provide suggestions when encountering `async fn` with a `dyn Trait` return type. Correctly address `type Alias = dyn Trait` when `fn foo() -> Alias { .. }`. Fix rust-lang#147894.

…szelmann Emit `check-cfg` lints during attribute parsing rather than evaluation The goal of this PR is to make the `eval_config_entry` not have any side effects, by moving the check-cfg lints to the attribute parsing. This also helps ensure we do emit the lint in situations where the attribute happens to be parsed, but never evaluated. cc `@jdonszelmann` `@Urgau` for a vibe check if you feel like it

Add release notes for 1.92.0 cc `@rust-lang/release` r? `@BoxyUwU`

rustdoc book: mention inner doc attribute Couldn't find this documented anywhere else.

lint: emit proper diagnostic for unsafe binders in improper_ctypes instead of ICE Fixes rust-lang#149719 This PR replaces the `todo!("FIXME(unsafe_binder)")` branch in the `improper_ctypes` lint with a proper diagnostic. Previously, using an unsafe binder inside an extern `"C"` block caused an internal compiler error. This fix now ensures that the compiler now emits a clear and stable error message explaining that types containing unsafe binders are not yet supported in FFI. A new UI test `(unsafe-binder-basic.rs)` is included to ensure this behavior remains stable and prevent regressions.

Zalathar · 2025-12-09T01:38:29Z

Rollup of everything.

@bors r+ rollup=never p=5

bors · 2025-12-09T01:38:32Z

📌 Commit 22e74c8 has been approved by Zalathar

It is now in the queue for this repository.

bors · 2025-12-09T01:48:03Z

⌛ Testing commit 22e74c8 with merge b77329d...

Rollup of 12 pull requests Successful merges: - #147572 (std: Use more `unix.rs` code on WASI targets) - #148491 ( Correctly provide suggestions when encountering `async fn` with a `dyn Trait` return type) - #149215 (Emit `check-cfg` lints during attribute parsing rather than evaluation) - #149652 (Add release notes for 1.92.0) - #149720 (rustdoc book: mention inner doc attribute) - #149730 (lint: emit proper diagnostic for unsafe binders in improper_ctypes instead of ICE) - #149754 (Retire `opt_str2` from compiletest cli parsing) - #149755 (bootstrap: Use a `CompiletestMode` enum instead of bare strings) - #149763 (Add inline attribute to generated delegation function if needed) - #149772 (test: Add a test for 146133) - #149779 (Fix typo "an" → "and") - #149782 (Remove `[no-mentions]` handler in the triagebot config) r? `@ghost` `@rustbot` modify labels: rollup

bors · 2025-12-09T01:57:38Z

💔 Test failed - checks-actions

rust-log-analyzer · 2025-12-09T01:59:30Z

The job tidy failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

warning ../../package.json: License should be a valid SPDX license expression
warning No license field
[1/4] Resolving packages...
[2/4] Fetching packages...
error Error: https://registry.yarnpkg.com/import-fresh/-/import-fresh-3.3.1.tgz: Request failed "500 Internal Server Error"
    at ResponseError.ExtendableBuiltin (/node/lib/node_modules/yarn/lib/cli.js:696:66)
    at new ResponseError (/node/lib/node_modules/yarn/lib/cli.js:802:124)
    at Request.<anonymous> (/node/lib/node_modules/yarn/lib/cli.js:66750:16)
    at Request.emit (node:events:518:28)
    at module.exports.Request.onRequestResponse (/node/lib/node_modules/yarn/lib/cli.js:142287:10)
    at ClientRequest.emit (node:events:518:28)
    at HTTPParser.parserOnIncomingClient (node:_http_client:698:27)
    at HTTPParser.parserOnHeadersComplete (node:_http_common:119:17)
    at TLSSocket.socketOnData (node:_http_client:540:22)
    at TLSSocket.emit (node:events:518:28)
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
yarn install did not exit successfully
tidy [extra_checks]: IO error: yarn install returned exit code exit status: 1
tidy [extra_checks]: FAIL
tidy: The following check failed: extra_checks
Bootstrap failed while executing `test src/tools/tidy tidyselftest --extra-checks=py,cpp,js,spellcheck`
Command `/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-tools-bin/rust-tidy /checkout /checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo /checkout/obj/build 4 /node/bin/yarn --extra-checks=py,cpp,js,spellcheck` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1612:23
Executed at: src/bootstrap/src/core/build_steps/test.rs:1320:29

Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:02:45
  local time: Tue Dec  9 01:56:47 UTC 2025
  network time: Tue, 09 Dec 2025 01:56:47 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

Zalathar · 2025-12-09T02:01:49Z

@bors retry (network request failed)

Zalathar · 2025-12-09T02:48:17Z

@bors try jobs=x86_64-msvc-1,i686-msvc-1,x86_64-mingw-1,test-various,armhf-gnu,aarch64-apple

Rollup of 12 pull requests try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1 try-job: test-various try-job: armhf-gnu try-job: aarch64-apple

bors · 2025-12-09T05:09:25Z

🔒 Merge conflict

This pull request and the default branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest default branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

git checkout rollup-fu656tl (switch to your branch)
git fetch upstream HEAD (retrieve the latest HEAD)
git rebase upstream/HEAD -p (rebase on top of it)
Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
git push self rollup-fu656tl --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message

Auto-merging tests/ui/cmse-nonsecure/cmse-nonsecure-entry/c-variadic.stderr
CONFLICT (content): Merge conflict in tests/ui/cmse-nonsecure/cmse-nonsecure-entry/c-variadic.stderr
Removing library/std/src/sys/thread/wasip2.rs
Removing library/std/src/sys/thread/wasip1.rs
Removing library/std/src/sys/stdio/wasip2.rs
Removing library/std/src/sys/stdio/wasip1.rs
Removing library/std/src/sys/pal/wasip2/time.rs
Removing library/std/src/sys/pal/wasip2/mod.rs
Removing library/std/src/sys/pal/wasip1/time.rs
Removing library/std/src/sys/pal/wasip1/mod.rs
Removing library/std/src/sys/pal/wasip1/helpers.rs
Removing library/std/src/sys/net/connection/socket/wasip2.rs
Removing library/std/src/sys/io/io_slice/wasi.rs
Removing library/std/src/sys/fs/wasi.rs
Removing library/std/src/sys/fd/wasi.rs
Automatic merge failed; fix conflicts and then commit the result.

rust-bors · 2025-12-09T05:57:28Z

☀️ Try build successful (CI)
Build commit: c35e277 (c35e2772bc54e0abb62200b2277fdc43c5a2628e, parent: 0b96731cd10757f695e99ba675ac26840ff85a79)

bors · 2025-12-09T06:38:03Z

☔ The latest upstream changes (presumably #149426) made this pull request unmergeable. Please resolve the merge conflicts.

JonathanBrouwer and others added 30 commits December 6, 2025 10:22

Emit check-cfg lints during attribute parsing rather than evaluatio…

71b093f

…n#149215

Changes to uitests

e7df904

Add regression test for nested cfgs

01576a6

rustdoc book: mention inner doc attribute

a3a041d

compiletest: require host/target flags specified

260b1ff

Instead of allowing them to be missing and using some placeholder "(none)" value instead.

compiletest: make presence/absence of adb-related options clear

a7ad214

Instead of possibly falling back to "(none)" when they are not specified.

compiletest: retire opt_str2

72541e9

We either have the value of a flag specified, or we don't. Use `Option<...>` to represent that -- don't invent a new "(none)" sentinel value...

Use a CompiletestMode enum in bootstrap

dc8cdb1

lint: treat unsafe binders in improper_ctypes instead of ICE

0f4ec28

Replaced _binder with _

test: Add test for 146133

611c956

Even if a crate is marked as #![no_builtins], we can still generate bitcode for rlib, but we cannot emit bitcode to the linker in rustc's LTO.

Add inline attribute to generated delegation function if needed

8cf942d

Fix typo "an" → "and"

27a4aab

Remove [no-mentions] handler in the triagebot config

b8581dd

https://github.blog/changelog/2025-11-07-removing-notifications-for-mentions-in-commit-messages/

Use return type Span on async fns instead of whole fn def Span

2ff91ca

Add test for dyn Trait in async fn return type

e6c4d4e

Account for async fn with dyn Trait return type in impl Trait s…

f8afd75

…uggestion

Add test for type Alias = dyn Trait in return type

e6b921a

Point at async fn return type instead of body in E0746

b5790d7

Provide boxing suggestion for type Alias = dyn Trait return type

9b42166

Account for async fn in traits and impls

fa40a06

Add release notes for 1.92.0

90d2477

Rollup merge of rust-lang#149652 - cuviper:relnotes-1.92.0, r=BoxyUwU

c5cda30

Add release notes for 1.92.0 cc `@rust-lang/release` r? `@BoxyUwU`

Rollup merge of rust-lang#149720 - jtracey:patch-1, r=notriddle

0209e95

rustdoc book: mention inner doc attribute Couldn't find this documented anywhere else.

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 Dec 9, 2025

Zalathar mentioned this pull request Dec 9, 2025

Move the libgccjit.so file in a target directory #149426

Merged

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 Dec 9, 2025

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 Dec 9, 2025

This comment has been minimized.

Sign in to view

bors 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 Dec 9, 2025

Zalathar closed this Dec 9, 2025

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Dec 9, 2025

Zalathar deleted the rollup-fu656tl branch December 9, 2025 05:21

bors added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Dec 9, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Rollup of 12 pull requests #149796

Rollup of 12 pull requests #149796

Uh oh!

Zalathar commented Dec 9, 2025 •

edited by rustbot

Loading

Uh oh!

Zalathar commented Dec 9, 2025

Uh oh!

bors commented Dec 9, 2025

Uh oh!

bors commented Dec 9, 2025

Uh oh!

bors commented Dec 9, 2025

Uh oh!

rust-log-analyzer commented Dec 9, 2025

Uh oh!

Zalathar commented Dec 9, 2025

Uh oh!

Zalathar commented Dec 9, 2025

Uh oh!

This comment has been minimized.

bors commented Dec 9, 2025

Uh oh!

rust-bors bot commented Dec 9, 2025

Uh oh!

bors commented Dec 9, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

15 participants

Uh oh!

Rollup of 12 pull requests #149796

Rollup of 12 pull requests #149796

Uh oh!

Conversation

Zalathar commented Dec 9, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Zalathar commented Dec 9, 2025

Uh oh!

bors commented Dec 9, 2025

Uh oh!

bors commented Dec 9, 2025

Uh oh!

bors commented Dec 9, 2025

Uh oh!

rust-log-analyzer commented Dec 9, 2025

Uh oh!

Zalathar commented Dec 9, 2025

Uh oh!

Zalathar commented Dec 9, 2025

Uh oh!

This comment has been minimized.

bors commented Dec 9, 2025

Uh oh!

rust-bors bot commented Dec 9, 2025

Uh oh!

bors commented Dec 9, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

15 participants

Zalathar commented Dec 9, 2025 •

edited by rustbot

Loading