Don't special-case llvm.* as nounwind by purplesyringa · Pull Request #144225 · rust-lang/rust

purplesyringa · 2025-07-20T16:01:43Z

Certain LLVM intrinsics, such as llvm.wasm.throw, can unwind. Marking them as nounwind causes us to skip cleanup of locals and optimize out catch_unwind under inlining or when llvm.wasm.throw is used directly by user code.

The motivation for forcibly marking llvm.* as nounwind is no longer present: most intrinsics are linked as extern "C" or other non-unwinding ABIs, so we won't codegen invoke for them anyway.

Closes #132416.

@rustbot label +T-compiler +A-panic

rustbot · 2025-07-20T16:01:48Z

r? @SparrowLii

rustbot has assigned @SparrowLii.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2025-07-20T16:01:51Z

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in compiler/rustc_codegen_ssa/src/codegen_attrs.rs

cc @jdonszelmann

purplesyringa · 2025-07-20T16:04:17Z

I'm not 100% sure there's no subtle issue here, even though throw seems to be the only intrinsic declared with extern "C-unwind" that I could find, so I'm obviously waiting on PR CI here.

SparrowLii · 2025-07-22T06:36:24Z

r? @workingjubilee :)

rustbot · 2025-07-22T06:36:29Z

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

nikic · 2025-07-22T08:23:46Z

This looks reasonable to me.

The motivation for forcibly marking llvm.* as nounwind is no longer present: most intrinsics are linked as extern "C" or other non-unwinding ABIs, so we won't codegen invoke for them anyway.

LLVM intrinsics should generally use the "unadjusted" ABI. It looks like we don't have "unadjusted-unwind", but I guess it can be added when needed...

bors · 2025-07-22T23:07:40Z

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

Certain LLVM intrinsics, such as `llvm.wasm.throw`, can unwind. Marking them as nounwind causes us to skip cleanup of locals and optimize out `catch_unwind` under inlining or when `llvm.wasm.throw` is used directly by user code. The motivation for forcibly marking llvm.* as nounwind is no longer present: most intrinsics are linked as `extern "C"` or other non-unwinding ABIs, so we won't codegen `invoke` for them anyway.

nikic · 2025-07-24T16:48:37Z

@bors r+

bors · 2025-07-24T16:48:40Z

📌 Commit ed11a39 has been approved by nikic

It is now in the queue for this repository.

…, r=nikic Don't special-case llvm.* as nounwind Certain LLVM intrinsics, such as `llvm.wasm.throw`, can unwind. Marking them as nounwind causes us to skip cleanup of locals and optimize out `catch_unwind` under inlining or when `llvm.wasm.throw` is used directly by user code. The motivation for forcibly marking llvm.* as nounwind is no longer present: most intrinsics are linked as `extern "C"` or other non-unwinding ABIs, so we won't codegen `invoke` for them anyway. Closes rust-lang#132416. `@rustbot` label +T-compiler +A-panic

Rollup of 16 pull requests Successful merges: - #142569 (Suggest clone in user-write-code instead of inside macro) - #143401 (tests: Don't check for self-printed output in std-backtrace.rs test) - #143424 (clippy fix: rely on autoderef) - #143970 (Update core::mem::copy documentation) - #143979 (Test fixes for Arm64EC Windows) - #144160 (tests: debuginfo: Work around or disable broken tests on powerpc) - #144200 (Tweak output for non-`Clone` values moved into closures) - #144209 (Don't emit two `assume`s in transmutes when one is a subset of the other) - #144225 (Don't special-case llvm.* as nounwind) - #144314 (Hint that choose_pivot returns index in bounds) - #144316 (bootstrap: Move musl-root fallback out of sanity check) - #144364 (Update `dlmalloc` dependency of libstd) - #144368 (resolve: Remove `Scope::CrateRoot`) - #144373 (remove deprecated Error::description in impls) - #144390 (Remove dead code and extend test coverage and diagnostics around it) - #144392 (rustc_public: Remove movability from `RigidTy/AggregateKind::Coroutine`) r? `@ghost` `@rustbot` modify labels: rollup

…, r=nikic Don't special-case llvm.* as nounwind Certain LLVM intrinsics, such as `llvm.wasm.throw`, can unwind. Marking them as nounwind causes us to skip cleanup of locals and optimize out `catch_unwind` under inlining or when `llvm.wasm.throw` is used directly by user code. The motivation for forcibly marking llvm.* as nounwind is no longer present: most intrinsics are linked as `extern "C"` or other non-unwinding ABIs, so we won't codegen `invoke` for them anyway. Closes rust-lang#132416. ``@rustbot`` label +T-compiler +A-panic

Rollup of 17 pull requests Successful merges: - #142569 (Suggest clone in user-write-code instead of inside macro) - #143401 (tests: Don't check for self-printed output in std-backtrace.rs test) - #143424 (clippy fix: rely on autoderef) - #143970 (Update core::mem::copy documentation) - #143979 (Test fixes for Arm64EC Windows) - #144160 (tests: debuginfo: Work around or disable broken tests on powerpc) - #144200 (Tweak output for non-`Clone` values moved into closures) - #144209 (Don't emit two `assume`s in transmutes when one is a subset of the other) - #144225 (Don't special-case llvm.* as nounwind) - #144314 (Hint that choose_pivot returns index in bounds) - #144316 (bootstrap: Move musl-root fallback out of sanity check) - #144340 (UI test suite clarity changes: Rename `tests/ui/SUMMARY.md` and update rustc dev guide on `error-pattern`) - #144364 (Update `dlmalloc` dependency of libstd) - #144368 (resolve: Remove `Scope::CrateRoot`) - #144390 (Remove dead code and extend test coverage and diagnostics around it) - #144392 (rustc_public: Remove movability from `RigidTy/AggregateKind::Coroutine`) - #144424 (Allow setting `release-blog-post` label with rustbot) r? `@ghost` `@rustbot` modify labels: rollup

matthiaskrgr · 2025-07-25T07:00:41Z

@bors r-
looks like this failed here #144428 (comment)

rustbot · 2025-07-25T12:08:43Z

stdarch is developed in its own repository. If possible, consider making this change to rust-lang/stdarch instead.

cc @Amanieu, @folkertdev, @sayantn

rust-bors · 2025-07-26T17:03:35Z

☀️ Try build successful (CI)
Build commit: 5319385 (53193856e5a4ac7cbbe00ed3c7f71acb23e65133, parent: 8708f3cd1f96d226f6420a58ebdd61aa0bc08b0a)

nikic · 2025-07-27T20:09:21Z

@bors r+

bors · 2025-07-27T20:09:24Z

📌 Commit 17519ae has been approved by nikic

It is now in the queue for this repository.

bors · 2025-07-27T23:05:51Z

⌛ Testing commit 17519ae with merge 2b5e239...

bors · 2025-07-28T02:07:58Z

☀️ Test successful - checks-actions
Approved by: nikic
Pushing 2b5e239 to master...

github-actions · 2025-07-28T02:11:14Z

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 f8e355c (parent) -> 2b5e239 (this PR)

Test differences

No test diffs found

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 2b5e239c6b86cde974b0ef0f8e23754fb08ff3c5 --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

x86_64-apple-2: 4780.3s -> 3601.6s (-24.7%)
dist-aarch64-linux: 8092.6s -> 6146.0s (-24.1%)
x86_64-apple-1: 9031.8s -> 6913.5s (-23.5%)
pr-check-2: 2532.3s -> 2142.6s (-15.4%)
dist-aarch64-apple: 5493.3s -> 6107.6s (11.2%)
x86_64-rust-for-linux: 2919.0s -> 2599.7s (-10.9%)
pr-check-1: 1715.5s -> 1535.6s (-10.5%)
x86_64-gnu-llvm-19: 2772.9s -> 2498.1s (-9.9%)
aarch64-apple: 5258.1s -> 5753.1s (9.4%)
i686-gnu-2: 5931.5s -> 5374.0s (-9.4%)

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 · 2025-07-28T03:35:20Z

Finished benchmarking commit (2b5e239): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 4.5%, secondary 2.8%)

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

	mean	range	count
Regressions ❌ (primary)	4.5%	[4.4%, 4.7%]	2
Regressions ❌ (secondary)	2.8%	[1.1%, 5.2%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	4.5%	[4.4%, 4.7%]	2

Cycles

Results (primary 2.0%)

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

	mean	range	count
Regressions ❌ (primary)	2.0%	[1.9%, 2.2%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.0%	[1.9%, 2.2%]	2

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 465.942s -> 467.432s (0.32%)
Artifact size: 376.74 MiB -> 376.83 MiB (0.02%)

…r=nikic Don't special-case llvm.* as nounwind Certain LLVM intrinsics, such as `llvm.wasm.throw`, can unwind. Marking them as nounwind causes us to skip cleanup of locals and optimize out `catch_unwind` under inlining or when `llvm.wasm.throw` is used directly by user code. The motivation for forcibly marking llvm.* as nounwind is no longer present: most intrinsics are linked as `extern "C"` or other non-unwinding ABIs, so we won't codegen `invoke` for them anyway. Closes rust-lang#132416. `@rustbot` label +T-compiler +A-panic

rustc assumes that regular `extern "Rust"` functions unwind only if the `unwind` panic runtime is linked. `throw` was annotated as such, but unwound unconditionally. This could cause UB when a crate built with `-C panic=abort` called `throw` from `core` built with `-C panic=unwind`, since no terminator was added to handle the panic arising from calling an allegedly non-unwinding `extern "Rust"` function. rustc was taught to recognize this condition since rust-lang#144225 and prevented such linkage, but this caused regressions in rust-lang#148246, since this meant that Emscripten projects could not be built with `-C panic=abort` without recompiling std. The most straightforward solution would be to move `throw` into the `panic_unwind` crate, so that it's only compiled if the panic runtime is guaranteed to be `unwind`, but this is messy due to our architecture. Instead, move it into `unwind::wasm`, which is only compiled for bare-metal targets that default to `panic = "abort"`, rendering the issue moot.

Move wasm `throw` intrinsic back to `unwind` Fixes #148246, less invasive than the previously proposed #148269. Removes the publicly visible unstable intrinsic tracked in #122465 since it's not clear how to export it in a sound manner. r? `@bjorn3` --- rustc assumes that regular `extern "Rust"` functions unwind only if the `unwind` panic runtime is linked. `throw` was annotated as such, but unwound unconditionally. This could cause UB when a crate built with `-C panic=abort` called `throw` from `core` built with `-C panic=unwind`, since no terminator was added to handle the panic arising from calling an allegedly non-unwinding `extern "Rust"` function. rustc was taught to recognize this condition since #144225 and prevented such linkage, but this caused regressions in #148246, since this meant that Emscripten projects could not be built with `-C panic=abort` without recompiling std. The most straightforward solution would be to move `throw` into the `panic_unwind` crate, so that it's only compiled if the panic runtime is guaranteed to be `unwind`, but this is messy due to our architecture. Instead, move it into `unwind::wasm`, which is only compiled for bare-metal targets that default to `panic = "abort"`, rendering the issue moot.

rustc assumes that regular `extern "Rust"` functions unwind only if the `unwind` panic runtime is linked. `throw` was annotated as such, but unwound unconditionally. This could cause UB when a crate built with `-C panic=abort` called `throw` from `core` built with `-C panic=unwind`, since no terminator was added to handle the panic arising from calling an allegedly non-unwinding `extern "Rust"` function. rustc was taught to recognize this condition since rust-lang/rust#144225 and prevented such linkage, but this caused regressions in rust-lang/rust#148246, since this meant that Emscripten projects could not be built with `-C panic=abort` without recompiling std. The most straightforward solution would be to move `throw` into the `panic_unwind` crate, so that it's only compiled if the panic runtime is guaranteed to be `unwind`, but this is messy due to our architecture. Instead, move it into `unwind::wasm`, which is only compiled for bare-metal targets that default to `panic = "abort"`, rendering the issue moot.

Move wasm `throw` intrinsic back to `unwind` Fixes rust-lang/rust#148246, less invasive than the previously proposed rust-lang/rust#148269. Removes the publicly visible unstable intrinsic tracked in rust-lang/rust#122465 since it's not clear how to export it in a sound manner. r? `@bjorn3` --- rustc assumes that regular `extern "Rust"` functions unwind only if the `unwind` panic runtime is linked. `throw` was annotated as such, but unwound unconditionally. This could cause UB when a crate built with `-C panic=abort` called `throw` from `core` built with `-C panic=unwind`, since no terminator was added to handle the panic arising from calling an allegedly non-unwinding `extern "Rust"` function. rustc was taught to recognize this condition since rust-lang/rust#144225 and prevented such linkage, but this caused regressions in rust-lang/rust#148246, since this meant that Emscripten projects could not be built with `-C panic=abort` without recompiling std. The most straightforward solution would be to move `throw` into the `panic_unwind` crate, so that it's only compiled if the panic runtime is guaranteed to be `unwind`, but this is messy due to our architecture. Instead, move it into `unwind::wasm`, which is only compiled for bare-metal targets that default to `panic = "abort"`, rendering the issue moot.

rustc assumes that regular `extern "Rust"` functions unwind only if the `unwind` panic runtime is linked. `throw` was annotated as such, but unwound unconditionally. This could cause UB when a crate built with `-C panic=abort` called `throw` from `core` built with `-C panic=unwind`, since no terminator was added to handle the panic arising from calling an allegedly non-unwinding `extern "Rust"` function. rustc was taught to recognize this condition since rust-lang/rust#144225 and prevented such linkage, but this caused regressions in rust-lang/rust#148246, since this meant that Emscripten projects could not be built with `-C panic=abort` without recompiling std. The most straightforward solution would be to move `throw` into the `panic_unwind` crate, so that it's only compiled if the panic runtime is guaranteed to be `unwind`, but this is messy due to our architecture. Instead, move it into `unwind::wasm`, which is only compiled for bare-metal targets that default to `panic = "abort"`, rendering the issue moot.

Move wasm `throw` intrinsic back to `unwind` Fixes rust-lang/rust#148246, less invasive than the previously proposed rust-lang/rust#148269. Removes the publicly visible unstable intrinsic tracked in rust-lang/rust#122465 since it's not clear how to export it in a sound manner. r? `@bjorn3` --- rustc assumes that regular `extern "Rust"` functions unwind only if the `unwind` panic runtime is linked. `throw` was annotated as such, but unwound unconditionally. This could cause UB when a crate built with `-C panic=abort` called `throw` from `core` built with `-C panic=unwind`, since no terminator was added to handle the panic arising from calling an allegedly non-unwinding `extern "Rust"` function. rustc was taught to recognize this condition since rust-lang/rust#144225 and prevented such linkage, but this caused regressions in rust-lang/rust#148246, since this meant that Emscripten projects could not be built with `-C panic=abort` without recompiling std. The most straightforward solution would be to move `throw` into the `panic_unwind` crate, so that it's only compiled if the panic runtime is guaranteed to be `unwind`, but this is messy due to our architecture. Instead, move it into `unwind::wasm`, which is only compiled for bare-metal targets that default to `panic = "abort"`, rendering the issue moot.

…r=nikic Don't special-case llvm.* as nounwind Certain LLVM intrinsics, such as `llvm.wasm.throw`, can unwind. Marking them as nounwind causes us to skip cleanup of locals and optimize out `catch_unwind` under inlining or when `llvm.wasm.throw` is used directly by user code. The motivation for forcibly marking llvm.* as nounwind is no longer present: most intrinsics are linked as `extern "C"` or other non-unwinding ABIs, so we won't codegen `invoke` for them anyway. Closes rust-lang#132416. `@rustbot` label +T-compiler +A-panic

…r=bjorn3 Move wasm `throw` intrinsic back to `unwind` Fixes rust-lang#148246, less invasive than the previously proposed rust-lang#148269. Removes the publicly visible unstable intrinsic tracked in rust-lang#122465 since it's not clear how to export it in a sound manner. r? `@bjorn3` --- rustc assumes that regular `extern "Rust"` functions unwind only if the `unwind` panic runtime is linked. `throw` was annotated as such, but unwound unconditionally. This could cause UB when a crate built with `-C panic=abort` called `throw` from `core` built with `-C panic=unwind`, since no terminator was added to handle the panic arising from calling an allegedly non-unwinding `extern "Rust"` function. rustc was taught to recognize this condition since rust-lang#144225 and prevented such linkage, but this caused regressions in rust-lang#148246, since this meant that Emscripten projects could not be built with `-C panic=abort` without recompiling std. The most straightforward solution would be to move `throw` into the `panic_unwind` crate, so that it's only compiled if the panic runtime is guaranteed to be `unwind`, but this is messy due to our architecture. Instead, move it into `unwind::wasm`, which is only compiled for bare-metal targets that default to `panic = "abort"`, rendering the issue moot.

…r=nikic Don't special-case llvm.* as nounwind Certain LLVM intrinsics, such as `llvm.wasm.throw`, can unwind. Marking them as nounwind causes us to skip cleanup of locals and optimize out `catch_unwind` under inlining or when `llvm.wasm.throw` is used directly by user code. The motivation for forcibly marking llvm.* as nounwind is no longer present: most intrinsics are linked as `extern "C"` or other non-unwinding ABIs, so we won't codegen `invoke` for them anyway. Closes rust-lang#132416. `@rustbot` label +T-compiler +A-panic

…r=bjorn3 Move wasm `throw` intrinsic back to `unwind` Fixes rust-lang#148246, less invasive than the previously proposed rust-lang#148269. Removes the publicly visible unstable intrinsic tracked in rust-lang#122465 since it's not clear how to export it in a sound manner. r? `@bjorn3` --- rustc assumes that regular `extern "Rust"` functions unwind only if the `unwind` panic runtime is linked. `throw` was annotated as such, but unwound unconditionally. This could cause UB when a crate built with `-C panic=abort` called `throw` from `core` built with `-C panic=unwind`, since no terminator was added to handle the panic arising from calling an allegedly non-unwinding `extern "Rust"` function. rustc was taught to recognize this condition since rust-lang#144225 and prevented such linkage, but this caused regressions in rust-lang#148246, since this meant that Emscripten projects could not be built with `-C panic=abort` without recompiling std. The most straightforward solution would be to move `throw` into the `panic_unwind` crate, so that it's only compiled if the panic runtime is guaranteed to be `unwind`, but this is messy due to our architecture. Instead, move it into `unwind::wasm`, which is only compiled for bare-metal targets that default to `panic = "abort"`, rendering the issue moot.

Move wasm `throw` intrinsic back to `unwind` Fixes rust-lang/rust#148246, less invasive than the previously proposed rust-lang/rust#148269. Removes the publicly visible unstable intrinsic tracked in rust-lang/rust#122465 since it's not clear how to export it in a sound manner. r? `@bjorn3` --- rustc assumes that regular `extern "Rust"` functions unwind only if the `unwind` panic runtime is linked. `throw` was annotated as such, but unwound unconditionally. This could cause UB when a crate built with `-C panic=abort` called `throw` from `core` built with `-C panic=unwind`, since no terminator was added to handle the panic arising from calling an allegedly non-unwinding `extern "Rust"` function. rustc was taught to recognize this condition since rust-lang/rust#144225 and prevented such linkage, but this caused regressions in rust-lang/rust#148246, since this meant that Emscripten projects could not be built with `-C panic=abort` without recompiling std. The most straightforward solution would be to move `throw` into the `panic_unwind` crate, so that it's only compiled if the panic runtime is guaranteed to be `unwind`, but this is messy due to our architecture. Instead, move it into `unwind::wasm`, which is only compiled for bare-metal targets that default to `panic = "abort"`, rendering the issue moot.

rustc assumes that regular `extern "Rust"` functions unwind only if the `unwind` panic runtime is linked. `throw` was annotated as such, but unwound unconditionally. This could cause UB when a crate built with `-C panic=abort` called `throw` from `core` built with `-C panic=unwind`, since no terminator was added to handle the panic arising from calling an allegedly non-unwinding `extern "Rust"` function. rustc was taught to recognize this condition since rust-lang#144225 and prevented such linkage, but this caused regressions in rust-lang#148246, since this meant that Emscripten projects could not be built with `-C panic=abort` without recompiling std. The most straightforward solution would be to move `throw` into the `panic_unwind` crate, so that it's only compiled if the panic runtime is guaranteed to be `unwind`, but this is messy due to our architecture. Instead, move it into `unwind::wasm`, which is only compiled for bare-metal targets that default to `panic = "abort"`, rendering the issue moot.

…r=bjorn3 Move wasm `throw` intrinsic back to `unwind` Fixes rust-lang#148246, less invasive than the previously proposed rust-lang#148269. Removes the publicly visible unstable intrinsic tracked in rust-lang#122465 since it's not clear how to export it in a sound manner. r? `@bjorn3` --- rustc assumes that regular `extern "Rust"` functions unwind only if the `unwind` panic runtime is linked. `throw` was annotated as such, but unwound unconditionally. This could cause UB when a crate built with `-C panic=abort` called `throw` from `core` built with `-C panic=unwind`, since no terminator was added to handle the panic arising from calling an allegedly non-unwinding `extern "Rust"` function. rustc was taught to recognize this condition since rust-lang#144225 and prevented such linkage, but this caused regressions in rust-lang#148246, since this meant that Emscripten projects could not be built with `-C panic=abort` without recompiling std. The most straightforward solution would be to move `throw` into the `panic_unwind` crate, so that it's only compiled if the panic runtime is guaranteed to be `unwind`, but this is messy due to our architecture. Instead, move it into `unwind::wasm`, which is only compiled for bare-metal targets that default to `panic = "abort"`, rendering the issue moot.

Move wasm `throw` intrinsic back to `unwind` Fixes rust-lang/rust#148246, less invasive than the previously proposed rust-lang/rust#148269. Removes the publicly visible unstable intrinsic tracked in rust-lang/rust#122465 since it's not clear how to export it in a sound manner. r? `@bjorn3` --- rustc assumes that regular `extern "Rust"` functions unwind only if the `unwind` panic runtime is linked. `throw` was annotated as such, but unwound unconditionally. This could cause UB when a crate built with `-C panic=abort` called `throw` from `core` built with `-C panic=unwind`, since no terminator was added to handle the panic arising from calling an allegedly non-unwinding `extern "Rust"` function. rustc was taught to recognize this condition since rust-lang/rust#144225 and prevented such linkage, but this caused regressions in rust-lang/rust#148246, since this meant that Emscripten projects could not be built with `-C panic=abort` without recompiling std. The most straightforward solution would be to move `throw` into the `panic_unwind` crate, so that it's only compiled if the panic runtime is guaranteed to be `unwind`, but this is messy due to our architecture. Instead, move it into `unwind::wasm`, which is only compiled for bare-metal targets that default to `panic = "abort"`, rendering the issue moot.

rustbot assigned SparrowLii Jul 20, 2025

rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) 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. labels Jul 20, 2025

rustbot added the A-panic Area: Panicking machinery label Jul 20, 2025

rustbot assigned workingjubilee and unassigned SparrowLii Jul 22, 2025

purplesyringa force-pushed the unwinding-intrinsics branch from 1233757 to ed11a39 Compare July 22, 2025 23:19

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 Jul 24, 2025

fmease mentioned this pull request Jul 24, 2025

Rollup of 16 pull requests #144418

Closed

fmease mentioned this pull request Jul 25, 2025

Rollup of 17 pull requests #144428

Closed

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 Jul 25, 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 Jul 27, 2025

bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 28, 2025

bors merged commit 2b5e239 into rust-lang:master Jul 28, 2025
12 checks passed

rustbot added this to the 1.90.0 milestone Jul 28, 2025

purplesyringa mentioned this pull request Aug 6, 2025

Support wasm exception handling for Emscripten target #112195

Closed

bjorn3 mentioned this pull request Oct 29, 2025

Core crate doesn't support panic="abort" in 1.90 wasm32-unknown-emscripten #148246

Closed

purplesyringa mentioned this pull request Oct 30, 2025

Move wasm throw intrinsic back to unwind #148291

Merged

Uh oh!

Conversation

purplesyringa commented Jul 20, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jul 20, 2025

Uh oh!

rustbot commented Jul 20, 2025

Uh oh!

purplesyringa commented Jul 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SparrowLii commented Jul 22, 2025

Uh oh!

rustbot commented Jul 22, 2025

Uh oh!

nikic commented Jul 22, 2025

Uh oh!

bors commented Jul 22, 2025

Uh oh!

nikic commented Jul 24, 2025

Uh oh!

bors commented Jul 24, 2025

Uh oh!

matthiaskrgr commented Jul 25, 2025

Uh oh!

rustbot commented Jul 25, 2025

Uh oh!

rust-bors Bot commented Jul 26, 2025

Uh oh!

nikic commented Jul 27, 2025

Uh oh!

bors commented Jul 27, 2025

Uh oh!

bors commented Jul 27, 2025

Uh oh!

bors commented Jul 28, 2025

Uh oh!

Uh oh!

github-actions Bot commented Jul 28, 2025

Test differences

Job duration changes

Uh oh!

rust-timer commented Jul 28, 2025

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

purplesyringa commented Jul 20, 2025 •

edited by rustbot

Loading

purplesyringa commented Jul 20, 2025 •

edited

Loading