prefer actual ABI-controling fields over target.abi when making ABI decisions by RalfJung · Pull Request #152941 · rust-lang/rust

RalfJung · 2026-02-21T16:22:44Z

We don't actually check that abi is consistent with the fields that control the ABI, e.g. one could set llvm_abiname to "ilp32e" on a riscv target without setting a matching abi. So, if we need to make actual decisions, better to use the source of truth we forward to LLVM than the informational string we forward to the user.

This is a breaking change for aarch64 JSON target specs: setting abi to "softfloat" is no longer enough; one has to also set rustc_abi to "softfloat". That is consistent with riscv and arm32, but it's still surprising. Cc @Darksonn in case this affects the Linux kernel.

Also see #153035 which does something similar for PowerPC, and Zulip. Happy to delay this PR if someone has a better idea.

Cc @folkertdev @workingjubilee

rustbot · 2026-02-21T16:22:49Z

r? @mati865

rustbot has assigned @mati865.
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: compiler
compiler expanded to 68 candidates
Random selection from 14 candidates

RalfJung · 2026-02-21T21:15:36Z

compiler/rustc_target/src/target_features.rs

-                    // Everything else is assumed to use a hardfloat ABI. neon and fp-armv8 must be enabled.
-                    // `FeatureConstraints` uses Rust feature names, hence only "neon" shows up.
-                    FeatureConstraints { required: &["neon"], incompatible: &[] }
+                match self.rustc_abi {


This actually seems like a great improvement in consistency; every other match in this function is about rustc_abi / llvm_abiname / llvm_floatabi.

Darksonn · 2026-02-22T17:56:34Z

Linux just uses the built-in aarch64-unknown-none-softfloat target. Target.json is only used on x86, where we do set rustc-abi to x86-softfloat.

RalfJung · 2026-02-22T17:59:37Z

Okay, sounds good then. (That value has been renamed to "softfloat" recently but we accept the old one as well.)

mati865

r=me with nit addressed

View changes since this review

compiler/rustc_target/src/spec/mod.rs

…ecisions

RalfJung · 2026-02-24T08:25:38Z

compiler/rustc_codegen_llvm/src/va_arg.rs

    // Rust does not currently support any powerpc softfloat targets.
    let target = &bx.cx.tcx.sess.target;
-    let is_soft_float_abi = target.abi == Abi::SoftFloat;
+    let is_soft_float_abi = target.rustc_abi == Some(RustcAbi::Softfloat);


We don't actually use RustcAbi::Softfloat on powerpc currently.
@Gelbpunkt Do we even have a powerpc softfloat target and how does it work? @folkertdev which target was this check supposed to deal with?

We don't have softfloat powerpc targets at the moment, but I'm pretty sure the RfL people will want to add one? Not sure what the plans are for that...

I assume we can then just leave this in in preparation for when a softfloat powerpc target gets added, since it'll presumably use the RustcAbi mechanism for that (AFAIK LLVM has no proper ABI control for powerpc). @folkertdev would still be nice if we could get a quick confirmation of that. :)

Oh wait I just realized we actually assert that this is non-softfloat immediately in the next line. Given precedent set for other targets then yeah checking rustc_abi here is definitely the right call; this just slipped through during review of the original code (hard to blame anyone for that, checking target.abi is extremely natural, but sadly wrong).

RalfJung · 2026-03-02T18:23:54Z

@bors r=mati865

rust-bors · 2026-03-02T18:23:57Z

📌 Commit c66597e has been approved by mati865

It is now in the queue for this repository.

workingjubilee · 2026-03-02T22:17:01Z

I wish we did something more structural here, as I've voiced, but I have no objection to this merging since the previous version also is Technically Wrong so like... Technically Right But Confusing is I guess a better starting ground for building a more structural change.

@Darksonn

prefer actual ABI-controling fields over target.abi when making ABI decisions We don't actually check that `abi` is consistent with the fields that control the ABI, e.g. one could set `llvm_abiname` to "ilp32e" on a riscv target without setting a matching `abi`. So, if we need to make actual decisions, better to use the source of truth we forward to LLVM than the informational string we forward to the user. This is a breaking change for aarch64 JSON target specs: setting `abi` to "softfloat" is no longer enough; one has to also set `rustc_abi` to "softfloat". That is consistent with riscv and arm32, but it's still surprising. Cc @Darksonn in case this affects the Linux kernel. Also see rust-lang#153035 which does something similar for PowerPC, and [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/De-spaghettifying.20ABI.20controls/with/575095372). Happy to delay this PR if someone has a better idea. Cc @folkertdev @workingjubilee

@Darksonn

prefer actual ABI-controling fields over target.abi when making ABI decisions We don't actually check that `abi` is consistent with the fields that control the ABI, e.g. one could set `llvm_abiname` to "ilp32e" on a riscv target without setting a matching `abi`. So, if we need to make actual decisions, better to use the source of truth we forward to LLVM than the informational string we forward to the user. This is a breaking change for aarch64 JSON target specs: setting `abi` to "softfloat" is no longer enough; one has to also set `rustc_abi` to "softfloat". That is consistent with riscv and arm32, but it's still surprising. Cc @Darksonn in case this affects the Linux kernel. Also see rust-lang#153035 which does something similar for PowerPC, and [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/De-spaghettifying.20ABI.20controls/with/575095372). Happy to delay this PR if someone has a better idea. Cc @folkertdev @workingjubilee

…uwer Rollup of 8 pull requests Successful merges: - #151864 (Implement AST -> HIR generics propagation in delegation) - #152941 (prefer actual ABI-controling fields over target.abi when making ABI decisions) - #153227 (Don’t report missing fields in struct exprs with syntax errors.) - #152966 (Migrate 11 tests from tests/ui/issues to specific directories) - #153003 (rustdoc: make `--emit` and `--out-dir` mimic rustc) - #153034 (Remove unhelpful hint from trivial bound errors) - #153221 (Add release notes for 1.94.0) - #153297 (Update the name of the Hermit operating system)

@Darksonn

prefer actual ABI-controling fields over target.abi when making ABI decisions We don't actually check that `abi` is consistent with the fields that control the ABI, e.g. one could set `llvm_abiname` to "ilp32e" on a riscv target without setting a matching `abi`. So, if we need to make actual decisions, better to use the source of truth we forward to LLVM than the informational string we forward to the user. This is a breaking change for aarch64 JSON target specs: setting `abi` to "softfloat" is no longer enough; one has to also set `rustc_abi` to "softfloat". That is consistent with riscv and arm32, but it's still surprising. Cc @Darksonn in case this affects the Linux kernel. Also see rust-lang#153035 which does something similar for PowerPC, and [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/De-spaghettifying.20ABI.20controls/with/575095372). Happy to delay this PR if someone has a better idea. Cc @folkertdev @workingjubilee

@Darksonn

prefer actual ABI-controling fields over target.abi when making ABI decisions We don't actually check that `abi` is consistent with the fields that control the ABI, e.g. one could set `llvm_abiname` to "ilp32e" on a riscv target without setting a matching `abi`. So, if we need to make actual decisions, better to use the source of truth we forward to LLVM than the informational string we forward to the user. This is a breaking change for aarch64 JSON target specs: setting `abi` to "softfloat" is no longer enough; one has to also set `rustc_abi` to "softfloat". That is consistent with riscv and arm32, but it's still surprising. Cc @Darksonn in case this affects the Linux kernel. Also see rust-lang#153035 which does something similar for PowerPC, and [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/De-spaghettifying.20ABI.20controls/with/575095372). Happy to delay this PR if someone has a better idea. Cc @folkertdev @workingjubilee

…uwer Rollup of 12 pull requests Successful merges: - #152941 (prefer actual ABI-controling fields over target.abi when making ABI decisions) - #153227 (Don’t report missing fields in struct exprs with syntax errors.) - #153265 (Clarified doc comments + added tests confirming current behavior for intersperse/intersperse_with) - #152966 (Migrate 11 tests from tests/ui/issues to specific directories) - #153003 (rustdoc: make `--emit` and `--out-dir` mimic rustc) - #153034 (Remove unhelpful hint from trivial bound errors) - #153152 (Migration of LintDiagnostic - part 5) - #153177 (disable the ptr_fragment_in_final test on s390x) - #153221 (Add release notes for 1.94.0) - #153279 (feat: Provide an '.item_kind()' method on ItemEnum) - #153297 (Update the name of the Hermit operating system) - #153309 (Cleanup of c-variadic link test)

RalfJung · 2026-03-03T07:33:56Z

You mean voiced here? As indicated in my reply, I'm not sure how that's supposed to fully replace rustc_abi.

rustbot assigned mati865 Feb 21, 2026

This comment has been minimized.

Sign in to view

RalfJung force-pushed the abi-control branch from 2ed4ab0 to b1fcdae Compare February 21, 2026 16:59

This comment has been minimized.

Sign in to view

RalfJung force-pushed the abi-control branch 2 times, most recently from f2e7433 to d7ea008 Compare February 21, 2026 21:13

RalfJung commented Feb 21, 2026

View reviewed changes

RalfJung added the relnotes Marks issues that should be documented in the release notes of the next release. label Feb 22, 2026

rustbot mentioned this pull request Feb 22, 2026

Tracking issue for release notes of #152941: prefer actual ABI-controling fields over target.abi when making ABI decisions #152983

Open

mati865 approved these changes Feb 23, 2026

View reviewed changes

compiler/rustc_target/src/spec/mod.rs Outdated Show resolved Hide resolved

prefer actual ABI-controling fields over target.abi when making ABI d…

c66597e

…ecisions

RalfJung force-pushed the abi-control branch from d7ea008 to c66597e Compare February 24, 2026 08:22

RalfJung commented Feb 24, 2026

View reviewed changes

rust-bors bot 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 Mar 2, 2026

JonathanBrouwer mentioned this pull request Mar 2, 2026

Rollup of 5 pull requests #153311

Closed

JonathanBrouwer mentioned this pull request Mar 2, 2026

Rollup of 8 pull requests #153315

Closed

JonathanBrouwer mentioned this pull request Mar 3, 2026

Rollup of 11 pull requests #153330

Closed

JonathanBrouwer mentioned this pull request Mar 3, 2026

Rollup of 12 pull requests #153331

Open

Uh oh!

Conversation

RalfJung commented Feb 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Feb 21, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

RalfJung Feb 21, 2026

Choose a reason for hiding this comment

Uh oh!

Darksonn commented Feb 22, 2026

Uh oh!

RalfJung commented Feb 22, 2026

Uh oh!

mati865 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

RalfJung Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Gelbpunkt Feb 25, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Mar 2, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Mar 2, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung commented Mar 2, 2026

Uh oh!

rust-bors bot commented Mar 2, 2026

Uh oh!

workingjubilee commented Mar 2, 2026

Uh oh!

RalfJung commented Mar 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

RalfJung commented Feb 21, 2026 •

edited

Loading

mati865 left a comment •

edited by rustbot

Loading

RalfJung Feb 24, 2026 •

edited

Loading