Make rustc implicitly use panic=abort for the panic_abort crate

[bjorn3]

The panic_abort crate must be compiled with panic=abort, but cargo doesn't allow setting the panic strategy for a single crate. Bootstrap handles this in its rustc wrapper, but for example the build systems of cg_clif and cg_gcc don't use a rustc wrapper, so they would either need to add one or be unable to build a sysroot suitable for both panic=abort and panic=unwind (as is currently the case).

There is a crate called panic_abort on crates.io that would also be affected by this change. This crate uses unstable features and has last been updated in 2019 however and seems to be meant to be used when you want panic=abort behavior anyway.

Required for rust-lang/rustc_codegen_cranelift#1567

[rustbot]

r? @petrochenkov

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

[petrochenkov]

It's less of a practical concern, but shouldn't panic_unwind also implicitly use panic=unwind?

I guess the proper solution would be to move fn panic_strategy from sess to tcx so it can use tcx.is_panic_runtime(), and extend the #![panic_runtime] attribute to #![panic_runtime = "abort|unwind"] to avoid relying on the crate name.
What do you think?

[petrochenkov]

Ah, crate loader still searches for panic_(unwind,abort) by crate name, but we can at least sanity check that the crate found that way is indeed #![panic_runtime = "unwind" or "abort"] respectively.

[bjorn3]

It's less of a practical concern, but shouldn't panic_unwind also implicitly use panic=unwind?

If panic=abort was used while compiling the standard library, panic_unwind won't be used anyway as any panic=abort dependency will force panic=abort to be used and thus panic_unwind doesn't get linked in.

I guess the proper solution would be to move fn panic_strategy from sess to tcx so it can use tcx.is_panic_runtime(), and extend the #![panic_runtime] attribute to #![panic_runtime = "abort|unwind"] to avoid relying on the crate name.
What do you think?

The LLVM backend needs to know if the current crate uses panic=unwind or panic=abort before any source code gets parsed:

rust/compiler/rustc_codegen_llvm/src/llvm_util.rs

Line 114 in 862156d

&& sess.panic_strategy() == PanicStrategy::Unwind

Ah, crate loader still searches for panic_(unwind,abort) by crate name, but we can at least sanity check that the crate found that way is indeed #![panic_runtime = "unwind" or "abort"] respectively.

There already is a sanity check that the found crate is a panic runtime:

rust/compiler/rustc_metadata/src/creader.rs

Lines 999 to 1001 in 862156d

	if !data.is_panic_runtime() {
	self.dcx().emit_err(errors::CrateNotPanicRuntime { crate_name: name });
	}

[bjorn3]

@rustbot ready

[petrochenkov]

@bors r+

[bors]

📌 Commit 7e58a46 has been approved by petrochenkov

It is now in the queue for this repository.

[klensy]

Should be possible with https://doc.rust-lang.org/cargo/reference/unstable.html#profile-rustflags-option ?

Something like (in case if it allowed to pass package name, didn't checked that):

[profile.release.package.panic_abort]
rustflags = [ "-C", "panic=abort" ]

[bjorn3]

Didn't know that was possible already. That is a much better solution.

@bors r-

[Kobzol]

Wouldn't that break -Zbuild-std? Actually, probably not, since this was done in the bootstrap wrapper before, which is also not used for -Zbuild-std.

[reneleonhardt]

Off-topic: Just wondering, Rust 1.87 depends on LLVM 20, but the Jobs are named 19? 🤔

aarch64-gnu-llvm-19-1

rust/src/ci/docker/scripts/build-clang.sh

Lines 7 to 8 in 18491d5

	# Try to keep the LLVM version here in sync with src/ci/scripts/install-clang.sh
	LLVM=llvmorg-20.1.0-rc2

rust/src/ci/scripts/install-clang.sh

Lines 13 to 14 in 036b5fc

	# Try to keep this in sync with src/ci/docker/scripts/build-clang.sh
	LLVM_VERSION="20.1.3"

https://github.com/llvm/llvm-project/releases/tag/llvmorg-20.1.7

Why not use renovate comments instead to group those 2 scripts together?
Or even easier, have only a central constant which both scripts use? 😄

[bjorn3]

Wouldn't that break -Zbuild-std? Actually, probably not, since this was done in the bootstrap wrapper before, which is also not used for -Zbuild-std.

I don't think it should break -Zbuild-std.

@rustbot ready

[Kobzol]

Off-topic: Just wondering, Rust 1.87 depends on LLVM 20, but the Jobs are named 19? 🤔

aarch64-gnu-llvm-19-1

rust/src/ci/docker/scripts/build-clang.sh

Lines 7 to 8 in 18491d5

	# Try to keep the LLVM version here in sync with src/ci/scripts/install-clang.sh
	LLVM=llvmorg-20.1.0-rc2

rust/src/ci/scripts/install-clang.sh

Lines 13 to 14 in 036b5fc

	# Try to keep this in sync with src/ci/docker/scripts/build-clang.sh
	LLVM_VERSION="20.1.3"

https://github.com/llvm/llvm-project/releases/tag/llvmorg-20.1.7

Why not use renovate comments instead to group those 2 scripts together? Or even easier, have only a central constant which both scripts use? 😄

We test rustc with the current LLVM (20) and one version before (19). The scripts that you link in different environments (inside/outside) Docker, and on different OSes, and they are not always fully synchronized.

[reneleonhardt]

We test rustc with the current LLVM (20) and one version before (19). The scripts that you link in different environments (inside/outside) Docker, and on different OSes, and they are not always fully synchronized.

Thanks for explaining, I created a PR to merge those versions if you're interested: #142786