Rename `target.abi` to `target.cfg_abi` and enum-ify llvm_abiname by RalfJung · Pull Request #153857 · rust-lang/rust

RalfJung · 2026-03-14T09:53:06Z

See Zulip for more context. Discussed a bit in #153769 (comment) too.

This renames target.abi to target.cfg_abi to make it less likely that someone will use it to determine things about the actual ccABI, i.e. the calling convention used on the target. target.abi does not control that calling convention, it just sometimes informs the user about that calling convention (and also about other aspects of the ABI).

Also turn llvm_abiname into an enum to make it more natural to match on.
Cc @workingjubilee @madsmtm

rustbot · 2026-03-14T09:53:10Z

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred in cfg and check-cfg configuration

cc @Urgau

rustbot · 2026-03-14T09:53:12Z

r? @jieyouxu

rustbot has assigned @jieyouxu.
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 69 candidates
Random selection from 15 candidates

RalfJung · 2026-03-14T09:53:49Z

compiler/rustc_codegen_llvm/src/context.rs

-    // If llvm_abiname is empty, emit nothing.
    let llvm_abiname = &sess.target.options.llvm_abiname;
-    if matches!(sess.target.arch, Arch::RiscV32 | Arch::RiscV64) && !llvm_abiname.is_empty() {
+    if matches!(sess.target.arch, Arch::RiscV32 | Arch::RiscV64) {


We force all riscv targets to set an ABI so no check for an empty ABI name is needed here.

RalfJung · 2026-03-14T09:55:15Z

compiler/rustc_codegen_ssa/src/back/metadata.rs

-                    bug!("No ABI specified for this PPC64 ELF target");
+                LlvmAbi::ElfV1 => EF_PPC64_ABI_ELF_V1,
+                LlvmAbi::ElfV2 => EF_PPC64_ABI_ELF_V2,
+                _ if sess.target.options.binary_format.to_object() == BinaryFormat::Elf => {


ElfV1 and ElfV2 are the only allowed ABI names here so we can error on everything else.

RalfJung · 2026-03-14T10:29:21Z

Also, to quote some of my arguments from #153769 where this change was first proposed (this was in reply to questions/comments by @madsmtm):

I kinda like that the fields on TargetOptions are named os, env and abi, and that they match target_os, target_env and target_abi.

I agree that it is a bummer to lose this consistency, but I think it's the preferable outcome over people misunderstanding what target.abi is or does.

But then again, I do also see your point that target.abi could be the wrong tool for the job in some cases. Do you have an example of a place where it's gone wrong in the past?

Yeah we just recently fixed a few of them

rustc_target: callconv: powerpc64: Use llvm_abiname rather than target_abi for ABI determination #153035
prefer actual ABI-controling fields over target.abi when making ABI decisions #152941
and arguably the vector extension situation on AIX is also an example of this

In both cases AFAIK all targets had a consistent value for target.abi and the actual ccABI, but given how target.abi also often has other values not indicative of the ccABI, I think it is a massive footgun for it to have the name that "obviously" sounds like it controls the ccABI, when really it is just loosely correlated. It's arguably gotten worse when the type of abi was made an enum as that makes it look more canonical than it really is. That's what motivated me to also enum-ify LlvmAbi.

Looking at the current usage, it seems like only has_reliable_f16_f128 and the comparisons with target.abi == Abi::Spe that may be suspect? The rest seem like they use target.abi for checking certain target capabilities, which seems like the right thing to use it for?

Yeah, agreed. has_reliable_f16_f128 is a hopefully temporary internal hack/heuristic so it's not very critical. I don't know anything about the SPE situation (hence the FIXME).

Another solution would be to rename enum Abi to enum CfgAbi, we should at least discuss which would be preferable?

You mean instead of or on top of the field rename? I'd be fine with doing both, but I do think we should do the field rename. target.abi is just too juicy of a name.

I guess part of the problem here is that target_abi is kinda shitty... And is being used for a bunch of stuff it shouldn't be (looking at you Abi::Sim and Abi::Uwp...).

Exactly.

Maybe we should instead focus on actually making target.abi able to represent this stuff well enough that rustc could use it for determining ABI details? I.e. somehow combine llvm_abiname, llvm_floatabi, rustc_abi and cfg_abi into one field. Is that at all feasible?

We discussed this a bit on Zulip but it's not clear what one could do. I think even if we do that, a PR like this one is a helpful first step to map the territory. Personally I have no concrete plans to further cleanup after this PR (mostly due to a lack of good ideas, and also because I don't want to touch the hot potato of actually changing the user-visible target_abi values which is a non-trivial transition).

jieyouxu · 2026-03-15T09:01:47Z

Maybe r? @workingjubilee (or Mads)

rustbot · 2026-03-15T09:01:51Z

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

rustbot · 2026-03-15T09:56:04Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Mark-Simulacrum

r=me if you don't want to wait for a specific reviewer... comments are mostly nits / questions rather than blocking feedback.

View changes since this review

Mark-Simulacrum · 2026-03-21T13:21:55Z

compiler/rustc_target/src/spec/mod.rs


 crate::target_spec_enum! {
-    pub enum Abi {
+    pub enum CfgAbi {


Maybe add a comment here? Seems like we ought to be able to say something about the meaning of CfgAbi vs LlvmAbi (below) vs. (maybe) ccABI (if that's defined anywhere).

The meaning is in the field, not the type... like, we could use this type elsewhere in the compiler. So I'm not sure why one would expect such docs on the type.

I think it would be confusing to reuse this for a different purpose (e.g., for directly passing to llvm or so). So even a short comment that the cfg here is cfg(target_abi = ...) seems plausible to me.

But definitely not blocking for this PR.

I did add a short comment, does that help?

Yeah, that's perfect. Thanks!

compiler/rustc_target/src/spec/mod.rs

Mark-Simulacrum · 2026-03-21T13:24:42Z

compiler/rustc_target/src/spec/mod.rs

+    /// In a target spec, this field generally *informs* the user about what the ABI is, but you
+    /// have to also set up other parts of the target spec to ensure that this information is
+    /// correct. In the rest of the compiler, do not check this field if what you actually need to


Is it accurate to say that users should be using this field for e.g. naked asm to determine the right calling convention to expect? Or what is the right way for user code to use this? (Doesn't necessarily need answering here, mostly curious on how useful this actually is).

We don't currently provide enough information to the user to determine the right calling convention -- e.g., on RISCV there are at least 4 of them and we don't set any cfg flag that would let users systematically observe them. target_abi sounds like maybe it should have that role, but historically it has been used for things that have nothing to do with the calling convention, such as whether this is a real iOS target or a simulated one, or whether this is a regular Windows binary or an UWP one.

This will need a thorough cleanup, which is non-trivial and might involve breaking changes or a new cfg value. I am not here to do that cleanup, I just want to document the current messy situation better so that it is less likely to lead to mistakes.

Yeah, that makes sense. Just making sure I have the right understanding.

Mark-Simulacrum · 2026-03-21T13:32:40Z

compiler/rustc_target/src/spec/mod.rs

+                            | CfgAbi::MacAbi
+                            | CfgAbi::Sim
+                            | CfgAbi::Unspecified
+                            | CfgAbi::Other(_)


fwiw it feels a little strange to restrict the list of known ABIs and then allow other... is it accurate that Other shouldn't be used by any built-in targets? Maybe we need some kind of lint for that?

Yeah I think that is the intent for Other. The idea for this check is to ensure that the "reserved" names we use for builtin targets are used consistently, while still allowing experimentation by JSON targets. We could skip the entire check for JSON targets but IMO if a JSON target uses a "reserved" name it should play by its rules.

Also this PR doesn't change that logic.

I added a consistency check ensuring that builtin targets don't use Other.

Mark-Simulacrum · 2026-03-22T10:29:46Z

r=me on the latest changes

RalfJung · 2026-03-22T10:50:39Z

@bors r=Mark-Simulacrum

rust-bors · 2026-03-22T10:50:43Z

📌 Commit 4a0b264 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

@workingjubilee

Rename `target.abi` to `target.cfg_abi` and enum-ify llvm_abiname See [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/De-spaghettifying.20ABI.20controls/with/578893542) for more context. Discussed a bit in rust-lang#153769 (comment) too. This renames `target.abi` to `target.cfg_abi` to make it less likely that someone will use it to determine things about the actual ccABI, i.e. the calling convention used on the target. `target.abi` does not control that calling convention, it just *sometimes* informs the user about that calling convention (and also about other aspects of the ABI). Also turn llvm_abiname into an enum to make it more natural to match on. Cc @workingjubilee @madsmtm

@workingjubilee

Rename `target.abi` to `target.cfg_abi` and enum-ify llvm_abiname See [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/De-spaghettifying.20ABI.20controls/with/578893542) for more context. Discussed a bit in rust-lang#153769 (comment) too. This renames `target.abi` to `target.cfg_abi` to make it less likely that someone will use it to determine things about the actual ccABI, i.e. the calling convention used on the target. `target.abi` does not control that calling convention, it just *sometimes* informs the user about that calling convention (and also about other aspects of the ABI). Also turn llvm_abiname into an enum to make it more natural to match on. Cc @workingjubilee @madsmtm

@workingjubilee

Rename `target.abi` to `target.cfg_abi` and enum-ify llvm_abiname See [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/De-spaghettifying.20ABI.20controls/with/578893542) for more context. Discussed a bit in rust-lang#153769 (comment) too. This renames `target.abi` to `target.cfg_abi` to make it less likely that someone will use it to determine things about the actual ccABI, i.e. the calling convention used on the target. `target.abi` does not control that calling convention, it just *sometimes* informs the user about that calling convention (and also about other aspects of the ABI). Also turn llvm_abiname into an enum to make it more natural to match on. Cc @workingjubilee @madsmtm

rustbot assigned jieyouxu Mar 14, 2026

RalfJung commented Mar 14, 2026

View reviewed changes

RalfJung force-pushed the cfg-abi branch 2 times, most recently from 9cc36ca to 2b82fad Compare March 14, 2026 10:28

RalfJung force-pushed the cfg-abi branch from 2b82fad to 1e14fb1 Compare March 14, 2026 11:23

rustbot assigned workingjubilee and unassigned jieyouxu Mar 15, 2026

RalfJung force-pushed the cfg-abi branch from 1e14fb1 to ae5696f Compare March 15, 2026 09:56

Mark-Simulacrum approved these changes Mar 21, 2026

View reviewed changes

RalfJung added 2 commits March 22, 2026 10:34

target specs: rename abi to cfg_abi

40ebcc0

enum-ify llvm_abiname

6b14876

RalfJung force-pushed the cfg-abi branch from ae5696f to 6b14876 Compare March 22, 2026 09:34

ensure Other variants are only used by JSON targets

4a0b264

RalfJung force-pushed the cfg-abi branch from 6d0e867 to 4a0b264 Compare March 22, 2026 09:39

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 22, 2026

JonathanBrouwer mentioned this pull request Mar 22, 2026

Rollup of 4 pull requests #154209

Closed

JonathanBrouwer mentioned this pull request Mar 22, 2026

Rollup of 3 pull requests #154212

Closed

JonathanBrouwer mentioned this pull request Mar 22, 2026

Rollup of 13 pull requests #154219

Open

Uh oh!

Conversation

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

Uh oh!

Uh oh!

rustbot commented Mar 14, 2026

Uh oh!

rustbot commented Mar 14, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Uh oh!

jieyouxu commented Mar 15, 2026

Uh oh!

rustbot commented Mar 15, 2026

Uh oh!

rustbot commented Mar 15, 2026

Uh oh!

Mark-Simulacrum 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Mark-Simulacrum commented Mar 22, 2026

Uh oh!

RalfJung commented Mar 22, 2026

Uh oh!

rust-bors bot commented Mar 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

RalfJung commented Mar 14, 2026 •

edited

Loading

RalfJung commented Mar 14, 2026 •

edited

Loading

Mark-Simulacrum left a comment •

edited by rustbot

Loading