Promote `riscv64a23-unknown-linux-gnu` to Tier 2 with host tools

[ZhongyaoChen]

Proposal

This proposal seeks to promote riscv64a23-unknown-linux-gnu from Tier 3 to Tier 2 with host tools, enabling the use of the Rust compiler and tools natively on RVA23 hosts.

Since RVA23 hardware is not yet available, some teams in my company develop RVA23-targeted apps using virtual machines. Tier 2 with host tools will allow these developers to use native builds of the Rust compiler and tools.

Requirements for Tier 2 with Host Tools

Depending on the target, its capabilities, its performance, and the likelihood of use for any given tool, the host tools provided for a tier 2 target may include only rustc and cargo, or may include additional tools such as clippy and rustfmt.

rustc, cargo, clippy and rustfmt are required.

Approval of host tools will take into account the additional time required to build the host tools, and the substantial additional storage required for the host tools.

Ack.

The host tools must have direct value to people other than the target's maintainers. (It may still be a niche target, but the host tools must not be exclusively useful for an inherently closed group.) This requirement will be evaluated independently from the corresponding tier 2 requirement. There must be a reasonable expectation that the host tools will be used, for purposes other than to prove that they can be used.

This target and host tools are intended for use by developers working on RISC-V software ecosystem.

The host tools must build and run reliably in CI (for all components that Rust's CI considers mandatory), though they may or may not pass tests.

Ack.

Building host tools for the target must not take substantially longer than building host tools for other targets, and should not substantially raise the maintenance burden of the CI infrastructure.

Ack.

The host tools must provide a substantively similar experience as on other targets, subject to reasonable target limitations.

Ack.

If the host tools for the platform would normally be expected to be signed or equivalent (e.g. if running unsigned binaries or similar involves a "developer mode" or an additional prompt), it must be possible for the Rust project's automated builds to apply the appropriate signature process, without any manual intervention by either Rust developers, target maintainers, or a third party. This process must meet the approval of the infrastructure team.

Works without a signature.

Providing host tools does not exempt a target from requirements to support cross-compilation if at all possible.

Some crates may need update. Working in progress.

All requirements for tier 2 apply.

Ack.

Mentors or Reviewers

If you have a reviewer or mentor in mind for this work, mention them here. You can put your own name here if you are planning to mentor the work.

Process

The main points of the Major Change Process are as follows:

• [x] File an issue describing the proposal.
• [ ] A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• [ ] Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

[rustbot]

[!IMPORTANT] This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[davidtwco]

We already have a tier two w/ host tools target for riscv64gc-unknown-linux-gnu, so this seems reasonable. Starting an FCP per our target promotion docs:

@rfcbot fcp merge

[rust-rfcbot]

Team member @davidtwco has proposed to merge this. The next step is review by the rest of the tagged team members:

• [ ] @Mark-Simulacrum
• [ ] @Noratrieb
• [x] @SparrowLii
• [x] @cjgillot
• [ ] @compiler-errors
• [x] @davidtwco
• [ ] @estebank
• [ ] @jieyouxu
• [ ] @matthewjasper
• [x] @nagisa
• [x] @oli-obk
• [x] @petrochenkov
• [x] @spastorino
• [ ] @wesleywiser

Concerns:

• no-hardware-available (https://github.com/rust-lang/compiler-team/issues/910#issuecomment-3302832854)
• unclear-justification (https://github.com/rust-lang/compiler-team/issues/910#issuecomment-3305030219)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[davidtwco]

@rfcbot concern no-hardware-available

#t-compiler/major changes > Promote `riscv64a23-unknown-linux-gnu` to… compiler-team#910 @ 💬

[workingjubilee]

This MCP explicitly acknowledges the requirements of the tier 2 host tools policy, but glosses over the more general tier 2 requirements.

At least one tier 2 requirement explicitly asks for "documentation to the satisfaction of the approving teams":

If introducing a new tier 2 or higher target that is identical to an existing Rust target except for the baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar, then the proposed target must document to the satisfaction of the approving teams why the specific difference in baseline expectations provides sufficient value to justify a separate target.

People seemed unclear on this point during discussion, so such justification should probably be added to the MCP so the team can decide whether it is enough.

I believe I cannot register a formal justify-difference concern with rfcbot.

[jieyouxu]

cf. @workingjubilee's concern above: https://github.com/rust-lang/compiler-team/issues/910#issuecomment-3305020651

@rfcbot concern unclear-justification

[petrochenkov]

From the compiler point of view this seems ok to me, the target is very similar to what already exists and won't bring additional maintenance burden. I guess adding it or not is mostly concern for the infra team, especially given that building and publishing host tools is required here. @rfcbot reviewed

[ZhongyaoChen]

Response to unclear-justification and no-hardware-available concern

This note gives the compiler team the context behind promoting riscv64a23-unknown-linux-gnu to Tier 2 with host tools.

---

Separate Target (Why Needed)

• RVA23 represents a major milestone in standardizing RISC-V platforms.
• Encodes the RVA23U64 server baseline explicitly in the target triple; avoids manually specifying feature lists via RUSTFLAGS="-C target-feature=+rva23u64" in every project.
• Matches real deployment: developers on RVA23 servers target their actual baseline.
• Minimal divergence from riscv64gc. Minimal incremental maintenance cost.

Tier 2 (Why Now)

• Tier 3 is unusable for developers: no rustup binaries/CI/prebuilt std.
• Tier 2 enables rustup target add, CI coverage, prebuilt std, and immediate cross-compilation from x86/ARM hosts.
• Ecosystem timing: OS distributions converge on RVA23 in 2025-2026 (e.g., Ubuntu, openEuler ); enabling Tier 2 now lets tooling, crates, and CI mature ahead of deployments.
• Hardware timeline: Ventana Veyron V2 (2025) and other announced RVA23‑compatible SoCs indicate near‑term availability (e.g., Zhihe A210, SpacemIT K3; Ventana).

Host Tools (Why Matter)

• Native rustc/cargo on RVA23 servers enables a first-class developer experience (no baseline mismatch, no per-project flags).
• Build performance: the compiler can benefit from RVA23 features (e.g., vectors), reducing compile times for large crates.
• Operational simplicity: consistent host/target baseline avoids using riscv64gc host toolchains while targeting RVA23.
• Policy: server-class targets should ship host tools, because these platforms are often both the deployment and development environment (e.g., x86_64-unknown-linux-gnu, aarch64-unknown-linux-gnu).

---

Suggestion

Given no available hardware today (another concern), as suggested in the Zulip discussion, maybe this MCP adopts a two-phase approach: start with Tier 2 without host tools first.

Two-phase plan:

• Phase 1 (now): Tier 2 without host tools to unlock rustup, CI, and cross-compilation.
• Phase 2 (when ready): add host tools once there are multiple generally available server platforms, RVA23-default distro images.