Uh oh!
There was an error while loading. Please reload this page.
Rollup of 6 pull requests - #156290
Merged
Merged
Conversation
This commit is some minor updates/restructuring in a few locations with the end result being supporting `-Cpanic=unwind` on WASI targets. This continues to be off-by-default insofar as WASI targets default to `-Cpanic=abort`, meaning that actually using anything in this commit requires `-Zbuild-std`. Specifically the changes made here are: * The self-contained sysroot for WASI targets now contains a copy of `libunwind.a` from wasi-sdk, first shipped with wasi-sdk-33 (also updated here). * The `unwind` crate here in this repository uses the `libunwind` module instead of the custom bare-metal wasm implementation of exceptions. This means that Rust uses the `_Unwind_*` symbols which allows it to interoperate with C/C++/etc. * Wasm targets are all updated to pass the LLVM argument `-wasm-use-legacy-eh=false` to differ from LLVM's/clang's default of using the legacy exception handling proposal for WebAssembly. This has no effect by default because `panic=abort` is used on most targets. Emscripten is exempted from this as the Emscripten target is explicitly intended to follow LLVM's/clang's defaults. * There's a single test in the test suite that links to the `panic_unwind` crate which ended up requiring `-Wexceptions` from Wasmtime, so the test parts were updated and Wasmtime was updated in CI, too. The net result of all of this is that this should not actually affect any WebAssembly target's default behavior. Optionally, though, WASI programs can be built with exception handling via: RUSTFLAGS='-Cpanic=unwind' cargo +nightly run -Z build-std --target wasm32-wasip2 Effectively `-Zbuild-std` and `-Cpanic=unwind` is all that's necessary to enable this support on wasm targets. Finally, this ends up closing 154593 as well. The WASI targets are now defined to use `-lunwind` to implement unwinding. This means that the in-tree definition of `__cpp_exception` is no longer of concern and the definition is always sourced externally. If Rust is linked with other C/C++ code using WASI then these idioms are compatible with wasi-sdk, for example, to use that as a linker. The main caveat is that when using an external linker the `-fwasm-exceptions` argument needs to be passed to `clang` for it to be able to find the `libunwind.a` library to link against. Closes 154593
…bjorn3 Support `-Cpanic=unwind` on WASI targets This commit is some minor updates/restructuring in a few locations with the end result being supporting `-Cpanic=unwind` on WASI targets. This continues to be off-by-default insofar as WASI targets default to `-Cpanic=abort`, meaning that actually using anything in this commit requires `-Zbuild-std`. Specifically the changes made here are: * The self-contained sysroot for WASI targets now contains a copy of `libunwind.a` from wasi-sdk, first shipped with wasi-sdk-33 (also updated here). * The `unwind` crate here in this repository uses the `libunwind` module instead of the custom bare-metal wasm implementation of exceptions. This means that Rust uses the `_Unwind_*` symbols which allows it to interoperate with C/C++/etc. * Wasm targets are all updated to pass the LLVM argument `-wasm-use-legacy-eh=false` to differ from LLVM's/clang's default of using the legacy exception handling proposal for WebAssembly. This has no effect by default because `panic=abort` is used on most targets. Emscripten is exempted from this as the Emscripten target is explicitly intended to follow LLVM's/clang's defaults. * There's a single test in the test suite that links to the `panic_unwind` crate which ended up requiring `-Wexceptions` from Wasmtime, so the test parts were updated and Wasmtime was updated in CI, too. The net result of all of this is that this should not actually affect any WebAssembly target's default behavior. Optionally, though, WASI programs can be built with exception handling via: RUSTFLAGS='-Cpanic=unwind' cargo +nightly run -Z build-std --target wasm32-wasip2 Effectively `-Zbuild-std` and `-Cpanic=unwind` is all that's necessary to enable this support on wasm targets. Finally, this ends up closing rust-lang#154593 as well. The WASI targets are now defined to use `-lunwind` to implement unwinding. This means that the in-tree definition of `__cpp_exception` is no longer of concern and the definition is always sourced externally. If Rust is linked with other C/C++ code using WASI then these idioms are compatible with wasi-sdk, for example, to use that as a linker. The main caveat is that when using an external linker the `-fwasm-exceptions` argument needs to be passed to `clang` for it to be able to find the `libunwind.a` library to link against. Closesrust-lang#154593
…rce-shared-first-version, r=oli-obk Experiment: Reborrow traits With this PR we now have basic functional Reborrow and CoerceShared traits. The current limitations are: 1. Reborrowable types can only have one lifetime parameter, so as to avoid having to figure out and store in rmeta the information of which lifetimes weaken during reborrowing. 2. Reborrowing of `&mut` wrappers is working (though I've not tested generic wrappers like `Option<&mut T>` yet), but CoerceShared of `&mut` wrappers currently causes an ICE. The remaining tasks to complete before I'd consider this PR mergeable are: - [x] Fix ICE on CoerceShared. Unfortunately this might require dipping into rmeta. - [x] Expand the tests to give a more complete view of the current state of the experiment. Reborrow traits experiment: rust-lang#145612 Co-authored by @dingxiangfei2009
…n-ice, r=lqd Add regression test for closure return ICE Fixesrust-lang#155893
core: drop unmapped ZSTs in array `map` Fixesrust-lang#152211. Alternative to rust-lang#152220 and rust-lang#152248. This makes the `Drain` type use the same ZST-handling strategy as `slice::IterMut`, which stores the remaining length instead of a one-past-the-end pointer when the type is a ZST. I've also removed the const-generic `N` parameter from `Drain` to avoid unnecessary monomorphizations.
Add a suite of ChunkedBitSet union/subtract/intersect test scenarios While working on rust-lang#153754, I found that these code paths are under-tested.
Add `sync` option to `-Z threads` to force synchronization on one thread This adds a `sync` option to `-Z threads` to force synchronization while still using one thread. This is useful to measure overhead of synchronization without the noise of additional threads.
JonathanBrouwer
commented
May 7, 2026
MemberAuthor
Contributor
This comment has been minimized.
This comment has been minimized.
rust-borsBot
pushed a commit
that referenced
this pull request
May 7, 2026
Rollup of 6 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 try-job: i686-msvc-2
This comment has been minimized.
This comment has been minimized.
Contributor
Contributor
Uh oh!
There was an error while loading. Please reload this page.
rust-timer
commented
May 8, 2026
Collaborator
📌 Perf builds for each rolled up PR:
previous master: f964de49bc In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Contributor
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 f964de4 (parent) -> 63b1dfc (this PR) Test differencesShow 62 test diffsStage 0
Stage 1
Stage 2
Additionally, 34 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 63b1dfc0e00fd6f8ad7cd8817fc712e7d9b7be59 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
This was referenced May 8, 2026
rust-timer
commented
May 8, 2026
Collaborator
Finished benchmarking commit (63b1dfc): comparison URL. Overall result: ❌✅ regressions and improvements - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -1.6%, secondary 1.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 5.1%, secondary 7.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 508.875s -> 498.27s (-2.08%) |
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
9 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:
-Cpanic=unwindon WASI targets #156061 (Support-Cpanic=unwindon WASI targets)map#152487 (core: drop unmapped ZSTs in arraymap)syncoption to-Z threadsto force synchronization on one thread #156198 (Addsyncoption to-Z threadsto force synchronization on one thread)r? @ghost
Create a similar rollup