Skip to content

fix: normalize cfg attributes for three-part Rust triples - #213

Open
theGlenn wants to merge 1 commit into
hermeticbuild:mainfrom
theGlenn:fix/cfg-parser-triple-normalization
Open

fix: normalize cfg attributes for three-part Rust triples#213
theGlenn wants to merge 1 commit into
hermeticbuild:mainfrom
theGlenn:fix/cfg-parser-triple-normalization

Conversation

@theGlenn

@theGlenn theGlenn commented Aug 7, 2026

Copy link
Copy Markdown

Hi @dzbarsky and team! Thanks again for reaching out to us and inviting us to upstream our Rust and LLVM patches. This is the first one.

Summary

  • Parse non-positional three-part triples, including Android EABI and bare-metal Arm targets.
  • Extend architecture normalization to Arm/Thumb, x86, PowerPC, and BPF spellings.
  • Derive pointer width from the normalized architecture while retaining the raw spelling for endianness.
  • Match longer ABI names first so eabihf is not reduced to eabi.

triple_to_cfg_attrs currently interprets armv7-linux-androideabi as target_os = "androideabi" and target_arch = "armv7", with no Unix family or eabi ABI. Dependencies gated by cfg(unix), cfg(target_os = "android"), or cfg(target_arch = "arm") are therefore omitted from 32-bit Android builds.

The repository's rules_rust triple parser already maps androideabi to android. This change brings cfg_parser.bzl in line with that behavior and with rustc --print cfg.

Validation

  • Added focused coverage for Android EABI, bare-metal Arm, architecture aliases, pointer width, endianness, ABI precedence, and unchanged four-part triples.
  • Expected values come from rustc --print cfg --target <triple>.
  • bazel test //rs/private:cfg_parser_tests passes.
  • bazel test //... passes (40/40 tests).

`triple_to_cfg_attrs` read every triple positionally, but a 3-part triple
is not positional: its third component may be an OS, a bare ABI, or an OS
with the ABI glued onto it. It also passed most raw architecture tokens
through as `target_arch`, which is not always what rustc reports.

The most damaging case is 32-bit Android. `armv7-linux-androideabi` and
`arm-linux-androideabi` resolved to `target_os = "androideabi"`,
`target_family = ""`, and `target_arch = "armv7"`. Builds succeeded, but
dependencies behind `cfg(unix)`, `cfg(target_os = "android")`, or
`cfg(target_arch = "arm")` were silently dropped.

- Parse non-positional Android EABI and bare-metal Arm triples.
- Extend architecture normalization beyond the existing RISC-V handling.
- Derive pointer width from the normalized architecture while preserving
  the raw spelling for endianness.
- Match longer ABI names first so `eabihf` is not reduced to `eabi`.

Add focused coverage using expected values from
`rustc --print cfg --target <triple>`.
@dzbarsky

Copy link
Copy Markdown
Member

Thanks for sending this up! It looks like a similar open PR but we had an unresolved question there #205 (comment) - wonder if you have thoughts on that bit? fyi @Geethree

@theGlenn

Copy link
Copy Markdown
Author

Hey @dzbarsky.

I finally had time to look at #205 and added my thoughts to the existing discussion.

The PRs overlap on target identity, but they take different approaches.

Since #205’s versioning question is still unresolved, I think #213 can land independently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants