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

[ZhongyaoChen]

Proposal

The earlier MCP (#910) proposed promoting riscv64a23-unknown-linux-gnu to Tier 2 with host tools. That request was deferred due to no-hardware-available and unclear-justification concerns.

As outlined in this comment and Zulip feedback, we open this new MCP to request promoting the riscv64a23-unknown-linux-gnu target from Tier 3 to Tier 2 without host tools first.

Earlier MCP #910 will hold on until hardware available.

Requirements for Tier 2 Without Host Tools

A tier 2 target must have value to people other than its maintainers.
A tier 2 target must have a designated team of developers.

Myself and @CaiWeiran will maintain this target.

The target must not place undue burden on Rust developers not specifically concerned with that target.

Same as Tier‑2 riscv64gc-unknown-linux-gnu, but defaults to rva23u64.

The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation, and explaining how to run tests for the target.

Will be included in the PR.

The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar.

Document in requirements. further details in the next PR.

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.

Refer to this link for clarification.

Tier 2 targets must not leave any significant portions of core or the standard library unimplemented or stubbed out, unless they cannot possibly be supported on the target. As an exception, a target identical to an existing tier 1 target except for lower baseline expectations for the OS, CPU, or similar, may propose to qualify as tier 2 (but not higher) without support for std if the target will primarily be used in no_std applications, to reduce the support burden for the standard library. In this case, evaluation of the proposed target's value will take this limitation into account.

support full standard library functionality.

The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team.

Use standard RISC-V codegen backend.

If the target supports C code, and the target has an interoperable calling convention for C code, the Rust target must support that C calling convention for the platform via extern "C".

Ack.

The target must build reliably in CI, for all components that Rust's CI considers mandatory.

Ack.

The approving teams may additionally require that a subset of tests pass in CI.

Local runs pass most tests.

Building the target in CI must not take substantially longer than the current slowest target in CI, and should not substantially raise the maintenance burden of the CI infrastructure.

Ack.

Tier 2 targets should, if at all possible, support cross-compiling.

Support.

In addition to the legal requirements for all targets (specified in the tier 3 requirements), because a tier 2 target typically involves the Rust project building and supplying various compiled binaries, incorporating the target and redistributing any resulting compiled binaries (e.g. built libraries, host tools if any) must not impose any onerous license requirements on any members of the Rust project, including infrastructure team members and those operating CI systems.

Ack.

Tier 2 targets must not impose burden on the authors of pull requests, or other developers in the community, to ensure that tests pass for the target.

CI run no tests for this target.

The target maintainers should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion.

Ack.

All requirements for tier 3 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:

• 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

[Noratrieb]

@rustbot second