Skip to content

Rollup of 8 pull requests#154815

Merged
rust-bors[bot] merged 19 commits intorust-lang:mainfrom
JonathanBrouwer:rollup-sdqRx2J
Apr 4, 2026
Merged

Rollup of 8 pull requests#154815
rust-bors[bot] merged 19 commits intorust-lang:mainfrom
JonathanBrouwer:rollup-sdqRx2J

Conversation

@JonathanBrouwer
Copy link
Copy Markdown
Contributor

Successful merges:

r? @ghost

Create a similar rollup

alexcrichton and others added 19 commits December 10, 2025 15:13
This commit updates how the linker is invoked on WebAssembly targets
(all of them) to avoid passing the `--allow-undefined` flag to the
linker. Historically, if I remember this correctly, when `wasm-ld` was
first integrated this was practically required because at the time it
was otherwise impossible to import a function from the host into a wasm
binary. Or, at least, I'm pretty sure that was why this was added.

At the time, as the documentation around this option indicates, it was
known that this was going to be a hazard. This doesn't match behavior on
native, for example, and can easily paper over what should be a linker
error with some sort of other obscure runtime error. An example is that
this program currently compiles and links, it just prints null:

    unsafe extern "C" {
        static nonexistent: u8;
    }

    fn main() {
        println!("{:?}", &raw const nonexistent);
    }

This can easily lead to mistakes like rust-lang/libc/4880 and defer what
should be a compile-time link error to weird or unusual behavior at link
time. Additionally, in the intervening time since `wasm-ld` was first
introduced here, lots has changed and notably this program works as
expected:

    #[link(wasm_import_module = "host")]
    unsafe extern "C" {
        fn foo();
    }

    fn main() {
        unsafe {
            foo();
        }
    }

Notably this continues to compile without error and the final wasm
binary indeed has an imported function from the host. What this change
means, however, is that this program:

    unsafe extern "C" {
        fn foo();
    }

    fn main() {
        unsafe {
            foo();
        }
    }

this currently compiles successfully and emits an import from the `env`
module. After this change, however, this will fail to compile with a
link error stating that the `foo` symbol is not defined.
Since the length of a path is treated as sorting criteria, and
every path that contains the query without exactly matching it
must be longer, exact matches will always sort first if they exist.
…ed, r=Mark-Simulacrum

rustc: Stop passing `--allow-undefined` on wasm targets

This commit updates how the linker is invoked on WebAssembly targets (all of them) to avoid passing the `--allow-undefined` flag to the linker. Historically, if I remember this correctly, when `wasm-ld` was first integrated this was practically required because at the time it was otherwise impossible to import a function from the host into a wasm binary. Or, at least, I'm pretty sure that was why this was added.

At the time, as the documentation around this option indicates, it was known that this was going to be a hazard. This doesn't match behavior on native, for example, and can easily paper over what should be a linker error with some sort of other obscure runtime error. An example is that this program currently compiles and links, it just prints null:

    unsafe extern "C" {
        static nonexistent: u8;
    }

    fn main() {
        println!("{:?}", &raw const nonexistent);
    }

This can easily lead to mistakes like rust-lang/libc#4880 and defer what should be a compile-time link error to weird or unusual behavior at link time. Additionally, in the intervening time since `wasm-ld` was first introduced here, lots has changed and notably this program works as expected:

    #[link(wasm_import_module = "host")]
    unsafe extern "C" {
        fn foo();
    }

    fn main() {
        unsafe {
            foo();
        }
    }

This continues to compile without error and the final wasm binary indeed has an imported function from the host. This program:

    unsafe extern "C" {
        fn foo();
    }

    fn main() {
        unsafe {
            foo();
        }
    }

this currently compiles successfully and emits an import from the `env` module. After this change, however, this will fail to compile with a link error stating that the `foo` symbol is not defined.
…lacrum

Clarified docs in std::sync::RwLock + added test to ensure that max reader count is respected

This addresses the issue with the [`std::sync::RwLock` docs](https://doc.rust-lang.org/std/sync/struct.RwLock.html) in rust-lang#115338. It centers around the following lines:

> An `RwLock` will allow any number of readers to acquire the lock as long as a writer is not holding the lock.

It's true that the `RwLock` in theory should allow any number of readers to acquire the lock when a writer is not holding it, but this may not be true in the implementation and could be os dependent. I decided to replace "any number of readers" to "multiple", so that it implies that more than 1 reader can acquire the lock, but you can't necessarily take away that this value is unbounded.

@rustbot label +A-docs
…=Mark-Simulacrum

Fix SGX delayed host lookup via ToSocketAddr

rust-lang#146541 introduced a regression in the `x86_64-fortanix-unknown-sgx` target, where arguments to TcpStream::connect and TcpListener::bind are no longer being passed down correctly to the underlying platform, resulting in connection/bind failures

* Add a test for the desired behavior (this test passes on Rust 1.33 through 1.91)
* Refactor lookup_host logic again

Fixes rust-lang#152848

cc @joboet
…asinh, r=tgross35

use libm for acosh and asinh

Fixes rust-lang#153878

Uses libm for `acosh` and `asinh`
…ark-Simulacrum

More informative `Debug for vec::ExtractIf`

While working on rust-lang#154318, I've realized that `vec::ExtractIf` actually maintains a valid prefix and a valid suffix in the underlying vector at all times with all the temporarily-invalid elements being only in the middle.

So why not make the `Debug` output more informative? I guess we could even expose something like `get_retained_mut(&mut self) -> &mut [T]` and `get_remainder_mut(&mut self) -> &mut [T]`, but that would add new backwards compatibility burden, unlike the `Debug` implementation, which (IIRC) can be changed at any time.
…acrum

Edit the docs new_in() and with_capacity_in()

I have updated the documentation for new_in().

While reviewing the code, I noticed that the documentation for with_capacity_in() was also inaccurate, so I have corrected it.

Close rust-lang#154452
…, r=Mark-Simulacrum

Panic/return false on overflow in no_threads read/try_read impl

As per discussion with Mark in rust-lang#153555, it's possible for `no_threads` impl of `RwLock` to trigger a silent overflow on `RwLock::read`/`RwLock::try_read` if we try to acquire more than `isize::MAX` read locks. This PR adds an explicit panic/return false when our read lock counter is at `isize::MAX` for `RwLock::read`/`RwLock::try_read`; the message is similar to that of sys/sync/rwlock/futex.rs [here](https://github.com/rust-lang/rust/blob/fb27476aaf1012f1f6ace6306f9b990e0d989c31/library/std/src/sys/sync/rwlock/futex.rs#L143).
…uillaumeGomez

rustdoc-search: match path components on words

Since the length of a path is treated as sorting criteria, and every path that contains the query without exactly matching it must be longer, exact matches will always sort first if they exist.

Fixes rust-lang#154733
@rust-bors rust-bors bot added the rollup A PR which is a rollup label Apr 4, 2026
@rustbot rustbot added A-run-make Area: port run-make Makefiles to rmake.rs A-rustdoc-js Area: Rustdoc's JS front-end A-rustdoc-search Area: Rustdoc's search feature 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-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 Apr 4, 2026
@JonathanBrouwer
Copy link
Copy Markdown
Contributor Author

@bors r+ rollup=never p=5

@rust-bors
Copy link
Copy Markdown
Contributor

rust-bors bot commented Apr 4, 2026

📌 Commit 4210825 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 Apr 4, 2026
@JonathanBrouwer
Copy link
Copy Markdown
Contributor Author

Trying commonly failed jobs
@bors try jobs=dist-various-1,test-various,x86_64-gnu-aux,x86_64-gnu-llvm-21-3,x86_64-msvc-1,aarch64-apple,x86_64-mingw-1

@rust-bors

This comment has been minimized.

rust-bors bot pushed a commit that referenced this pull request Apr 4, 2026
Rollup of 8 pull requests


try-job: dist-various-1
try-job: test-various
try-job: x86_64-gnu-aux
try-job: x86_64-gnu-llvm-21-3
try-job: x86_64-msvc-1
try-job: aarch64-apple
try-job: x86_64-mingw-1
@rust-bors

This comment has been minimized.

@rust-bors
Copy link
Copy Markdown
Contributor

rust-bors bot commented Apr 4, 2026

☀️ Try build successful (CI)
Build commit: 1245ffe (1245ffe0d825db25ee979caa4b8346490f9d248c, parent: 981cf69479ded5e2de0cf9e16111c19d65be0369)

@rust-bors rust-bors bot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Apr 4, 2026
@rust-bors
Copy link
Copy Markdown
Contributor

rust-bors bot commented Apr 4, 2026

☀️ Test successful - CI
Approved by: JonathanBrouwer
Duration: 3h 13m 33s
Pushing e0e95a7 to main...

@rust-bors rust-bors bot merged commit e0e95a7 into rust-lang:main Apr 4, 2026
13 checks passed
@rustbot rustbot added this to the 1.96.0 milestone Apr 4, 2026
@rust-timer
Copy link
Copy Markdown
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#149868 rustc: Stop passing --allow-undefined on wasm targets 76508bc0110fcb68b80e6314e39f9478512841a8 (link)
#152851 Fix SGX delayed host lookup via ToSocketAddr 28d1f37c207261936cd5b3819c9713b9389ac425 (link)
#153555 Clarified docs in std::sync::RwLock + added test to ensure … 983f4c9bac5e29b6b63eb51992e1c02cd5ceed6b (link)
#154051 use libm for acosh and asinh 94c5e672471214aa5b95937933f91c7f8581db18 (link)
#154461 Edit the docs new_in() and with_capacity_in() 60149013b7318273dc7bb4d5c7afea24d775c219 (link)
#154526 Panic/return false on overflow in no_threads read/try_read … eea132cff1686bf339468029375024a96e965868 (link)
#154581 More informative Debug for vec::ExtractIf 8def7d0b997617e4270a24f515f88971936c386a (link)
#154798 rustdoc-search: match path components on words aebce355b8ab8717f5e105419f916a9e49d5ff0d (link)

previous master: 0312a55fe4

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Apr 4, 2026

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 0312a55 (parent) -> e0e95a7 (this PR)

Test differences

Show 2098 test diffs

Stage 1

  • rwlock::test_rwlock_max_readers: [missing] -> pass (J0)
  • [rustdoc-js] tests/rustdoc-js/path-substring.rs: [missing] -> pass (J3)

Stage 2

  • rwlock::test_rwlock_max_readers: [missing] -> pass (J1)
  • [rustdoc-js] tests/rustdoc-js/path-substring.rs: [missing] -> pass (J2)

Additionally, 2094 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard e0e95a71872dfe9e15d22bddea9ac45c85ddda1a --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. dist-i686-mingw: 2h 42m -> 2h 4m (-23.6%)
  2. dist-arm-linux-musl: 1h 19m -> 1h 36m (+22.3%)
  3. x86_64-gnu-llvm-21: 1h 6m -> 1h 20m (+21.6%)
  4. i686-gnu-2: 1h 26m -> 1h 43m (+19.0%)
  5. pr-check-1: 28m 6s -> 33m 14s (+18.2%)
  6. i686-gnu-1: 2h 7m -> 2h 26m (+14.8%)
  7. pr-check-2: 38m 43s -> 43m 29s (+12.3%)
  8. aarch64-gnu-debug: 1h 6m -> 1h 14m (+11.9%)
  9. x86_64-rust-for-linux: 47m 20s -> 52m 46s (+11.5%)
  10. test-various: 1h 53m -> 2h 6m (+11.2%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Copy Markdown
Collaborator

Finished benchmarking commit (e0e95a7): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

@rustbot label: -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.6% [0.0%, 1.6%] 3
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.1% [-0.1%, -0.0%] 2
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary 2.2%, secondary -0.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
2.2% [2.2%, 2.2%] 1
Regressions ❌
(secondary)
2.9% [0.9%, 4.5%] 5
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-3.0% [-5.4%, -0.5%] 8
All ❌✅ (primary) 2.2% [2.2%, 2.2%] 1

Cycles

Results (primary 1.1%, secondary 2.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
3.2% [2.7%, 3.7%] 2
Regressions ❌
(secondary)
3.8% [2.2%, 5.1%] 7
Improvements ✅
(primary)
-2.9% [-2.9%, -2.9%] 1
Improvements ✅
(secondary)
-3.2% [-4.2%, -2.2%] 2
All ❌✅ (primary) 1.1% [-2.9%, 3.7%] 3

Binary size

Results (primary 0.0%, secondary 0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
0.0% [0.0%, 0.0%] 4
Regressions ❌
(secondary)
0.0% [0.0%, 0.0%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.0% [0.0%, 0.0%] 4

Bootstrap: 489.356s -> 489.285s (-0.01%)
Artifact size: 395.11 MiB -> 395.03 MiB (-0.02%)

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

Labels

A-run-make Area: port run-make Makefiles to rmake.rs A-rustdoc-js Area: Rustdoc's JS front-end A-rustdoc-search Area: Rustdoc's search feature merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup T-compiler Relevant to the compiler 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.

10 participants