Rollup of 10 pull requests#154222
Closed
JonathanBrouwer wants to merge 25 commits intorust-lang:mainfrom
Closed
Conversation
Instead of relying on the linker to find the 'environ' symbol, use dlsym. Fixes rust-lang#153451 Sponsored by: ConnectWise
Currently, building std for a custom Wasm target with an OS other than `unknown` will fail, because `sys/alloc/mod.rs` will attempt to use `sys/alloc/wasm.rs`, the dlmalloc-based allocator used on `wasm32-unknown-unknown`. However, currently dlmalloc is only pulled in when `target_os = "unknown"`. Instead, we should make `Cargo.toml` and `alloc/mod.rs` match: either - disable `wasm.rs` in `alloc/mod.rs` where `not(target_os = "unknown")`, or - pull in `dlmalloc` for all Wasm targets with `target_family = "wasm32"` that aren't covered by the [upper branches of `alloc/mod.rs`](https://github.com/rust-lang/rust/blob/main/library/std/src/sys/alloc/mod.rs#L72-L100). This PR takes the latter approach, because it allows more code to compile without a custom allocator.
…d documentation + tests
This improves startup performance by 16%, shown by an optimized hello-world program. glibc's `pthread_getattr_np` performs expensive syscalls when reading `/proc/self/maps`. That is all wasted with `panic = immediate-abort` active because `init()` immediately discards the return value from `install_main_guard()`. A similar improvement can be seen in environments that don't have `/proc`. This change is safe because the immediately succeeding comment says that we rely on Linux's "own stack-guard mechanism".
Both zstd and zlib are *known* compression algorithms, they just may not be supported by the backend. We shouldn't mislead users into e.g. thinking they made a typo.
`std`: include `dlmalloc` for all non-wasi Wasm targets Currently, building std for a custom Wasm target with an OS other than `unknown` will fail, because `sys/alloc/mod.rs` will attempt to use `sys/alloc/wasm.rs`, the dlmalloc-based allocator used on `wasm32-unknown-unknown`. However, currently dlmalloc is only pulled in when `target_os = "unknown"`. Instead, we should make `Cargo.toml` and `alloc/mod.rs` match: either - disable `wasm.rs` in `alloc/mod.rs` where `not(target_os = "unknown")`, or - pull in `dlmalloc` for all Wasm targets with `target_family = "wasm32"` that aren't covered by the [upper branches of `alloc/mod.rs`](https://github.com/rust-lang/rust/blob/main/library/std/src/sys/alloc/mod.rs#L72-L100). This PR takes the latter approach, because it allows more code to compile without a custom allocator.
…mulacrum Fix environ on FreeBSD with cdylib targets that use -Wl,--no-undefined . Instead of relying on the linker to find the 'environ' symbol, use dlsym. This fixes using `environ` from cdylibs that link with `-Wl,--no-undefined` . Fixes rust-lang#153451 Sponsored by: ConnectWise
…Mark-Simulacrum Lifted intersperse and intersperse_with Fused transformation and updated documentation + tests This PR once again builds on top of rust-lang#152855. From the discussion in rust-lang#152855, libs team came to the conclusion that `intersperse`/`intersperse_with` shouldn't transform the given iterator to a fused iterator always and a separator should be emitted between `Some(_)` items for non fused iterators (particularly just right before the subsequent `Some(_)`). On top of the change Zakarumych added in the PR, I lifted the `FusedIterator` trait and transformation of the inner `iter` for `Intersperse`/`IntersperseWith`, so that we can display this behavior. I've adjusted the documentation and tests accordingly to reflect this change as well. r? @jhpratt
remove usages of to-be-deprecated numeric constants Split out from rust-lang#146882.
…on-warn, r=JonathanBrouwer Unknown -> Unsupported compression algorithm Both zstd and zlib are *known* compression algorithms, they just may not be supported by the backend. We shouldn't mislead users into e.g. thinking they made a typo. cc rust-lang#120953
std: move `sys::pal::os` to `sys::paths` Part of rust-lang#117276. After rust-lang#150723, rust-lang#153130, rust-lang#153341 and rust-lang#153413, `sys::pal::os` only contains default-path related functions (like `getcwd` and the `PATH`-splitting logic). In line with rust-lang#117276, this PR thus moves all these implementations into a new module in `sys`: `sys::paths`. ~There is one functional change here: The `chdir` implementation on SGX used to use `sgx_ineffective` which silently fails, but now returns an error unconditionally – I think that's much more reasonable given that SGX doesn't support filesystem stuff at all.~ I've corrected the misleading panic messages in `temp_dir` for UEFI and WASI, aside from that, this PR only consists of code moves. CC @jethrogb @raoulstrackx @aditijannu for the SGX change (resolved)
…process, r=Mark-Simulacrum docs(fs): Clarify That File::lock Coordinates Across Processes ### Summary: The documentation for `lock`, `lock_shared`, `try_lock`, and `try_lock_shared` did not make it clear that these are OS level file locks that coordinate access across processes, not just between handles within the current process. Add "in this or any other process" to each method's existing description to clarify this. Fixes rust-lang#153618 r? @Mark-Simulacrum
…dPthreadGetattrNp, r=Mark-Simulacrum Skip stack_start_aligned for immediate-abort This improves startup performance by 16%, shown by an optimized hello-world program. glibc's `pthread_getattr_np` performs expensive syscalls when reading `/proc/self/maps`. That is all wasted with `panic = immediate-abort` active because `init()` immediately discards the return value from `install_main_guard()`. A similar improvement can be seen in environments that don't have `/proc`. This change is safe because the immediately succeeding comment says that we rely on Linux's "own stack-guard mechanism". Tracking issue: rust-lang#147286 # Benchmark Set it up with `cargo new hello-world2`, and replace these files: ```toml # Cargo.toml cargo-features = ["panic-immediate-abort"] [package] name = "hello-world" version = "0.1.0" edition = "2024" [profile.release] lto = true panic = "immediate-abort" codegen-units = 1 opt-level = "z" strip = true # .cargo/config.toml [unstable] build-std = ["std"] ``` ## Before ```console home@daniel-desktop3:~/CLionProjects/hello-world2$ hyperfine -N target/release/hello-world2 Benchmark 1: target/release/hello-world2 Time (mean ± σ): 524.8 µs ± 65.1 µs [User: 276.1 µs, System: 187.0 µs] Range (min … max): 446.4 µs … 975.5 µs 3996 runs home@daniel-desktop3:~/CLionProjects/hello-world2$ hyperfine -N target/release/hello-world2 Benchmark 1: target/release/hello-world2 Time (mean ± σ): 519.4 µs ± 65.8 µs [User: 282.1 µs, System: 177.7 µs] Range (min … max): 443.2 µs … 830.5 µs 3612 runs home@daniel-desktop3:~/CLionProjects/hello-world2$ hyperfine -N target/release/hello-world2 Benchmark 1: target/release/hello-world2 Time (mean ± σ): 520.0 µs ± 64.3 µs [User: 277.1 µs, System: 182.1 µs] Range (min … max): 447.1 µs … 1001.3 µs 3804 runs ``` For a visualization of the problem, run `cargo +stage1 build --release && perf record --call-graph dwarf -F max ./target/release/hello-world2 && perf script | inferno-collapse-perf | inferno-flamegraph > flamegraph.svg`: <img width="3832" height="1216" alt="flamegraph with 17.41% __pthread_getattr_np" src="https://github.com/user-attachments/assets/acc2286e-1582-4772-9e3b-68b5c35e3e70" /> ## After ```console home@daniel-desktop3:~/CLionProjects/hello-world2$ hyperfine -N target/release/hello-world2Benchmark 1: target/release/hello-world2 Time (mean ± σ): 444.7 µs ± 57.3 µs [User: 257.4 µs, System: 130.2 µs] Range (min … max): 379.4 µs … 1289.3 µs 3893 runs Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options. home@daniel-desktop3:~/CLionProjects/hello-world2$ hyperfine -N target/release/hello-world2 Benchmark 1: target/release/hello-world2 Time (mean ± σ): 452.3 µs ± 60.7 µs [User: 261.5 µs, System: 133.5 µs] Range (min … max): 374.9 µs … 1512.4 µs 4177 runs Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options. home@daniel-desktop3:~/CLionProjects/hello-world2$ hyperfine -N target/release/hello-world2 Benchmark 1: target/release/hello-world2 Time (mean ± σ): 441.2 µs ± 56.1 µs [User: 256.2 µs, System: 128.8 µs] Range (min … max): 375.0 µs … 760.4 µs 4032 runs ```
…=Mark-Simulacrum implement `BinaryHeap::as_mut_slice` Tracking issue: rust-lang#154009
…ts, r=Kivooeo
ui/lto: move and rename two tests from issues/
Move:
- `tests/ui/issues/issue-44056.rs` -> `tests/ui/lto/lto-avx-target-feature.rs`
- The first test enables both AVX target features and LTO but does not exercise AVX-specific behavior. The test primarily checks that LTO builds successfully with these flags; place it under `ui/lto` for consistency.
- `tests/ui/issues/issue-51947.rs` -> `tests/ui/lto/lto-weak-merge-functions.rs`
- The second test exercises weak linkage interacting with LTO (merge-functions), so it should belong in `ui/lto`.
I have also added a commented line at the top of each test file indicating the issue it originated from.
rustbot
added
A-LLVM
rustbot
added
O-solid
Contributor
Author
|
@bors r+ rollup=never p=3 |
Contributor
Contributor
Author
|
Trying commonly failed jobs |
rust-bors
bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Mar 22, 2026
Rollup of 10 pull requests 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
Contributor
Author
|
Just wanted to get some try jobs started already, feel free to recreate this PR when more stuff enters the queue |
rust-bors
bot
added
S-waiting-on-author
Contributor
|
This pull request was unapproved due to being closed. |
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
std: includedlmallocfor all non-wasi Wasm targets #153686 (std: includedlmallocfor all non-wasi Wasm targets)sys::pal::ostosys::paths#153623 (std: movesys::pal::ostosys::paths)BinaryHeap::as_mut_slice#154011 (implementBinaryHeap::as_mut_slice)r? @ghost
Create a similar rollup