Amend target policy to require codegen support

[workingjubilee]

Proposal

We may wish to adopt the recommendation by @nikic to amend the target tier policy to explicitly require codegen support for all target architectures that rustc actually supports. While strongly implied¹²³ by the policy, it's left slightly ambiguous. Recent events have undermined certainty that all targets in-tree functionally support even emitting object code, leading to inadequate returns on our own maintenance efforts.

More specifically, I would elaborate this to require:

• All target architectures must have a cross-compilable assembly test
  • "emit correct assembly" is usually LLVM's job, but is useless if rustc is incorrectly configured
  • describes a minimum for tier 3: "can ANYTHING build if you twist rustc's arm hard enough?"
• Significant variants of architectures should test to validate the variant is emitted correctly
  • For instance, aarch64_ilp32 might test the pointers are actually 32-bit
• For tier 3, quality of codegen is not required, merely codegen
• Tiers 1 and 2 need an upstream machine backend maintainer/reviewer group/codeowner/etc.

Mentors or Reviewers

@nikic?
@workingjubilee?

Process

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

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

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.

Footnotes

1. "Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries" suggests that such compilation can be done but does not directly state that it can happen. ↩

2. "Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality)," does not explicitly say, say, addition should work. ↩

3. "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." does not specify, for instance, that these implementations should emit the correct object code and survive even minimal testing... it just seems reasonable to imagine they would. ↩

[rustbot]

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.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[nagisa]

@rustbot second

[compiler-errors]

This MCP is accepted.