abort in core by CAD97 · Pull Request #154604 · rust-lang/rust

CAD97 · 2026-03-30T20:11:30Z

Implements core::process::abort_immediate as a wrapper around intrinsics::abort.

tracking issue: Tracking Issue for abort_immediate (abort in core) #154601

(This PR used to also add core::process::abort, but that's been deferred to a later addition.)

rustbot · 2026-03-30T20:11:34Z

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

rustbot · 2026-03-30T20:11:37Z

r? @scottmcm

rustbot has assigned @scottmcm.
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

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @scottmcm, libs
@scottmcm, libs expanded to 8 candidates
Random selection from Mark-Simulacrum, scottmcm

CAD97 · 2026-03-30T20:21:54Z

tests/ui/extern-flag and tests/ui/no_std caught that __rust_abort still wasn't being defined. I think this must be because std is available (and thus lang = "abort_impl" is defined, but #![no_std] means that we aren't linking std. I'm now looking for how to directly gate the shim on if std is getting linked, to avoid adding a new requirement to no_std binaries.

RalfJung · 2026-03-30T20:48:30Z

Cc @bjorn3 who knows a lot about the alloc shims.

RalfJung · 2026-03-30T20:49:08Z

library/core/src/process.rs

+pub mod __default_core_abort {
+    #[rustc_std_internal_symbol]
+    pub fn __rdl_abort() -> ! {
+        super::abort_immediate()
+    }
+}


This looks like it wants to be an externally defined item...

EIIs still don’t work on Windows.

I would stongly prefer waiting until EIIs are ready before we add any more EII like interfaces.

RalfJung · 2026-03-30T20:54:19Z

library/core/src/process.rs

+    }
+
+    __rust_abort()
+}


Would you mind adding a Miri test for this, to ensure the symbol dispatch also works there? Ideally with two revisions to cover both the no_std and with_std case. src/tools/miri/tests/fail/shims is probably the right folder for that.

bjorn3 · 2026-03-30T21:38:44Z

compiler/rustc_codegen_ssa/src/base.rs

+            inputs: &[],
+            output: AllocatorTy::Never,
+        });
+    }


The allocator shim is only codegened when liballoc is pulled in.

bjorn3 · 2026-03-30T21:47:24Z

Imagine the following scenario:

liba depends on libcore and gets linked as dylib
libb depends on liba and libstd

When building liba, we need to already generate the __rust_abort symbol, but would conflict with the one from libstd. This is not a breaking change on most targets as due to what is arguably a bug in rustc, in this scenario rustc will report an error about libcore getting linked twice. If however you remove libstd.so or link for a target for which we don't ship libstd as dylib yet do still support dynamic linking (i don't know if any such target exists. maybe a wasm target?), then this scenario would currently work fine, but break with this PR.

Also cc @anforowicz for Chromium which bypasses the allocator shim. I think it will be fine for you as you include libstd, but I'm not sure if you don't have any no_std executables. It is probably more of an issue for Bazel.

anforowicz · 2026-03-30T22:14:38Z

Also cc @anforowicz for Chromium which bypasses the allocator shim. I think it will be fine for you as you include libstd, but I'm not sure if you don't have any no_std executables.

Thank you for the heads-up.

I think it doesn't impact Chromium, because Chromium product builds link everything statically (no dylibs, only rlibs that are at the end linked by non-rustc-driven linker).
OTOH we are currently working on building std into a dylib in developer builds (and later plan to expand this to some other libraries - e.g. the log crate). But this still seems ok, because I think that Chromium doesn't have a library like liba (linked as dylib, but depends on core and not on std).
That said, I don't fully understand the changes in this PR, so I defer to your judgement / I don't really understand if these changes may require a follow-up in Chromium when/if they get absorbed.

/cc @DKLoehr from the Chromium Toolchain team as FYI

CAD97 · 2026-03-30T22:26:14Z

Given core abort is essentially blocked on EIIs being ready, would it make sense to PR abort_immediate separately first?

CAD97 · 2026-03-30T22:58:41Z

I decided to rebase this branch/PR to just include abort_immediate, which is useful on its own. abort can be added later once EII can be utilized to do so properly.

jyn514 · 2026-03-30T23:26:53Z

library/core/src/process.rs

+/// # Platform-specific behavior
+///
+/// `abort_immediate` lowers to a trap instruction on *most* architectures; on
+/// some architectures it simply lowers to call the unmangled `abort` function.


"unmangled" you mean libc::abort?

rustbot added 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. labels Mar 30, 2026

rustbot assigned scottmcm Mar 30, 2026

RalfJung reviewed Mar 30, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

bjorn3 reviewed Mar 30, 2026

View reviewed changes

add abort_immediate

3a311ed

CAD97 force-pushed the abort-immediate branch from 807cd4e to 3a311ed Compare March 30, 2026 22:56

CAD97 mentioned this pull request Mar 30, 2026

Tracking Issue for abort_immediate (abort in core) #154601

Open

4 tasks

This comment has been minimized.

Sign in to view

add missing core::process module docs

fb99fbe

jyn514 reviewed Mar 30, 2026

View reviewed changes

Uh oh!

Conversation

CAD97 commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Mar 30, 2026

Uh oh!

rustbot commented Mar 30, 2026

Uh oh!

CAD97 commented Mar 30, 2026

Uh oh!

RalfJung commented Mar 30, 2026

Uh oh!

RalfJung Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

jyn514 Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

bjorn3 Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

bjorn3 Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

bjorn3 commented Mar 30, 2026

Uh oh!

anforowicz commented Mar 30, 2026

Uh oh!

CAD97 commented Mar 30, 2026

Uh oh!

CAD97 commented Mar 30, 2026

Uh oh!

This comment has been minimized.

jyn514 Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

CAD97 commented Mar 30, 2026 •

edited

Loading