Pass -Cpanic=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 the usual way using panic="abort", but luckily per-package rustflags do allow this. Bootstrap previously handled this in its rustc wrapper, but for example the build systems of cg_clif and cg_gcc don't use the rustc wrapper, so they would either need to add one, patch the standard library or be unable to build a sysroot suitable for both panic=abort and panic=unwind (as is currently the case).

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

[petrochenkov]

Cargo works in mysterious ways, why does it allow to specify rustflags per-profile, but doesn't allow to just specify rustflags regardless of profile?

In any case, from reading https://doc.rust-lang.org/cargo/reference/profiles.html it looks like all profiles (including the remaining built-in ones) ultimately inherit from either dev or release, so what this PR does should work.
@bors r+

[bors]

📌 Commit a0badba has been approved by petrochenkov

It is now in the queue for this repository.