Drop MIPS to tier 3

[workingjubilee]

Proposal

The target tier policy exists to guarantee targets have a minimum of support and don't cause problems in our CI. The existing tier 2 MIPS targets are causing problems in our CI. Specifically, cross builds from x86-64 hosts to build toolchains suitable for deployment on these hosts:

target	std	notes
mips-unknown-linux-gnu	MIPS Linux (kernel 4.4, glibc 2.23)
mips64-unknown-linux-gnuabi64	MIPS64 Linux, n64 ABI (kernel 4.4, glibc 2.23)
mips64el-unknown-linux-gnuabi64	MIPS64 (LE) Linux, n64 ABI (kernel 4.4, glibc 2.23)
mipsel-unknown-linux-gnu	MIPS (LE) Linux (kernel 4.4, glibc 2.23)

Judging by issue rust-lang/rust#113065 this appears to be caused by problems that emerge during isel in LLVM. No one has emerged with an emergency patch to our LLVM fork which resolves the build for these targets. We have opened llvm/llvm-project#63608 upstream but it has yet to receive an acknowledgement that anyone is working on it. Certainly I do not expect anyone to suddenly wave their magic wand and simply banish these problems, but with no efforts to improve maintenance for them coming forward except for the mips{32,64}r6 targets, which are actually different ISAs due to backwards incompatibility, it is apparent this is a clear violation of both the spirit¹²³⁴ and letter⁵⁶⁷ of the target tier policy. I recommend we immediately drop all of these problematic targets to tier 3 per the target tier policy⁸⁹.

I have left ambiguous the fate of the following tier 2 targets without host tools. I have not observed them causing a problem yet, but it is apparent to me they are not actually receiving tier 2 maintenance, either. The lack of problems may be more of a feature of the GNU targets causing problems first, or it may be a feature of them exercising less of the compiler due to only building the stdlib's binary artifacts and whatever support necessary.

target	std	notes
mips-unknown-linux-musl	✓	MIPS Linux with MUSL
mips64-unknown-linux-muslabi64	✓	MIPS64 Linux, n64 ABI, MUSL
mips64el-unknown-linux-muslabi64	✓	MIPS64 (LE) Linux, n64 ABI, MUSL
mipsel-unknown-linux-musl	✓	MIPS (LE) Linux with MUSL

Mentors or Reviewers

• @Nilstrieb

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. • 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.
   ↩
2. • 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. This requirement is subjective, to be evaluated by the infrastructure team, and will take the community importance of the target into account.
   ↩
3. • 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.
   ↩
4. • Providing host tools does not exempt a target from requirements to support cross-compilation if at all possible.
   ↩
5. • 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.
   ↩
6. • Tier 2 targets should, if at all possible, support cross-compiling. Tier 2 targets should not require using the target as the host for builds, even if the target supports host tools.
   ↩
7. • The target must build reliably in CI, for all components that Rust's CI considers mandatory.
   ↩
8. • A tier 2 target may be demoted or removed if it no longer meets these requirements. Any proposal for demotion or removal will be CCed to the target maintainers, and will be communicated widely to the Rust community before being dropped from a stable release.
   ↩
9. • In some circumstances, especially if the target maintainers do not respond in a timely fashion, Rust teams may land pull requests that temporarily disable some targets in the nightly compiler, in order to implement a feature not yet supported by those targets.
   ↩

[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

[compiler-errors]

@rustbot second

[Noratrieb]

It's important it explicitly add that if someone steps up, fixes these issues and volunteers to be a target maintainer, we can promote them again.