"Legacy" tier 2 targets have misplaced or absent maintainer docs

[workingjubilee]

Location

This affects our platform support documentation.

It specifically affects targets added before the target tier policy was confirmed, and especially those that are tier 2.

Summary

It is widely expected that the existing tier 1 targets are of primary concern for the Rust Project in general. As I understand it, the current absence of formally documented maintainers for them is based on the belief we have a large enough surplus of "target maintainers" for them that we can expect these targets to be effectively supported by "whoever picks up the slack".

However, tier 2 targets are trickier. Many are more niche, harder to find and run code on, and require specialized developer knowledge. These realities are part of why we expect targets to have target maintainers. Yet we have several without any documented support because they predate the target tier policy. This has recently led to us being forced to respond to exigent circumstances by interrupting our usual support because they implicitly violated the other side of the target support "contract": they impeded development of all the rest of our targets to a degree we cannot accept, with little other recourse.

This is a very bad situation. It is also a bad situation we can attempt to reduce recurrence of. Easily, in fact. Some of our targets have informally known target maintainers but we just... haven't written them down. Actually writing down who is invested in these targets in the same way other maintainers are listed would help reduce the need for guessing when responding in future high-priority situations where failure to act could stall-out work.

We should formally document target maintainers for the following tier 2 targets on the now-common platform support documentation pages. Technically this concern applies somewhat even to tier 3 targets as well but those should be handled in a separate issue as they are quite literally a separate priority level, and because tier 2 targets are unique in having potential to move to both tier 1 and tier 3. We may need to reduce our asserted support level for some of these targets. We also might like to raise our support level for others, without having to maintain our existing assumptions of having essentially infinite "slack" for them.

Tier 2 with Host Tools

• aarch64-apple-darwin: Arm64 macOS (11.0+, Big Sur+)
• aarch64-pc-windows-msvc: Arm64 Windows MSVC
• aarch64-unknown-linux-musl: Arm64 Linux with musl libc
• arm-unknown-linux-gnueabi: Armv6 Linux (kernel 3.2, glibc 2.17)
• arm-unknown-linux-gnueabihf: Armv6 Linux, hardfloat (kernel 3.2, glibc 2.17)
• armv7-unknown-linux-gnueabihf: Armv7-A Linux, hardfloat (kernel 3.2, glibc 2.17)
• powerpc-unknown-linux-gnu: PowerPC Linux (kernel 3.2, glibc 2.17)
• powerpc64-unknown-linux-gnu: PPC64 Linux (kernel 3.2, glibc 2.17)
• powerpc64le-unknown-linux-gnu: PPC64LE Linux (kernel 3.10, glibc 2.17)
• riscv64gc-unknown-linux-gnu: RISC-V Linux (kernel 4.20, glibc 2.29)
• s390x-unknown-linux-gnu: S390x Linux (kernel 3.2, glibc 2.17)
• x86_64-unknown-freebsd: 64-bit FreeBSD
• x86_64-unknown-illumos: illumos
• x86_64-unknown-linux-musl: 64-bit Linux with musl libc

Tier 2

• aarch64-apple-ios: Arm64 iOS
• aarch64-unknown-none-softfloat: Bare Arm64, softfloat
• aarch64-unknown-none: Bare Arm64, hardfloat
• arm-unknown-linux-musleabi: Armv6 Linux with musl libc
• arm-unknown-linux-musleabihf: Armv6 Linux with musl libc, hardfloat
• armebv7r-none-eabi: Bare Armv7-R, Big Endian
• armebv7r-none-eabihf: Bare Armv7-R, Big Endian, hardfloat
• armv5te-unknown-linux-gnueabi: Armv5TE Linux (kernel 4.4, glibc 2.23)
• armv5te-unknown-linux-musleabi: Armv5TE Linux with musl libc
• armv7-unknown-linux-gnueabi: Armv7-A Linux (kernel 4.15, glibc 2.27)
• armv7-unknown-linux-musleabi: Armv7-A Linux with musl libc
• armv7-unknown-linux-musleabihf: Armv7-A Linux with musl libc, hardfloat
• armv7a-none-eabi: Bare Armv7-A
• armv7r-none-eabi: Bare Armv7-R
• armv7r-none-eabihf: Bare Armv7-R, hardfloat
• asmjs-unknown-emscripten: asm.js via Emscripten
• i586-pc-windows-msvc: 32-bit Windows w/o SSE
• i586-unknown-linux-gnu: 32-bit Linux w/o SSE (kernel 3.2, glibc 2.17)
• i586-unknown-linux-musl: 32-bit Linux w/o SSE, musl libc
• i686-unknown-freebsd: 32-bit FreeBSD
• i686-unknown-linux-musl: 32-bit Linux with musl libc
• riscv32i-unknown-none-elf: Bare RISC-V (RV32I ISA)
• riscv32imac-unknown-none-elf: Bare RISC-V (RV32IMAC ISA)
• riscv32imc-unknown-none-elf: Bare RISC-V (RV32IMC ISA)
• riscv64gc-unknown-none-elf: Bare RISC-V (RV64IMAFDC ISA)
• riscv64imac-unknown-none-elf: Bare RISC-V (RV64IMAC ISA)
• sparc64-unknown-linux-gnu: SPARC Linux (kernel 4.4, glibc 2.23)
• sparcv9-sun-solaris: SPARC Solaris 10/11
  • now has one target maintainer, but we need two
• thumbv6m-none-eabi: Bare Armv6-M
• thumbv7em-none-eabi: Bare Armv7E-M
• thumbv7em-none-eabihf: Bare ArmV7E-M, hardfloat
• thumbv7m-none-eabi: Bare Armv7-M
• thumbv7neon-unknown-linux-gnueabihf: Thumb2-mode Armv7-A Linux with NEON (kernel 4.4, glibc 2.23)
• thumbv8m.base-none-eabi: Bare Armv8-M Baseline
• thumbv8m.main-none-eabi: Bare Armv8-M Mainline
• thumbv8m.main-none-eabihf: Bare Armv8-M Mainline, hardfloat
• wasm32-unknown-emscripten: WebAssembly via Emscripten
• wasm32-unknown-unknown: WebAssembly
• wasm32-wasi: WebAssembly with WASI
• x86_64-apple-ios: 64-bit x86 iOS
• x86_64-pc-solaris: 64-bit Solaris 10/11
  • now has one target maintainer, but we need two
• x86_64-unknown-linux-gnux32: 64-bit Linux (x32 ABI) (kernel 4.15, glibc 2.27)
• x86_64-unknown-redox: Redox OS

[thomcc]

I can volunteer as a maintainer for at least these three.

• aarch64-apple-darwin
• aarch64-apple-ios
• x86_64-apple-ios (which is the x86_64 iOS simulator target, despite the name).

It's worth noting that for many of these there's not a clean place in the documentation to mark a target maintainer.

[workingjubilee]

There is definitely a certain degree to which this issue is really about us needing to better organize our documentation and our "search for maintainers" is about finding our !s with our own two hands, given that we do have the ping groups, and the platform support docs, but it's... inconsistent. I started a T-compiler discussion on Zulip about this.

[jonathanpallant]

Related to this, I found a weird codegen issue on the thumbv7em-none-eabi and thumbv7em-none-eabihf targets when specifying -C target-cpu=xxx and I don't know who to ask about it.

[apiraino]

Issue discussed during weekly T-compiler triage meeting on Zulip (notes). Feels like this topic will need a separate discussion, possibly involving other teams. So, leaving nominated for now to figure that out.

[jacobbramley]

From this earlier comment (but continuing it here since that seems more appropriate):

I was under the impression that Arm Ltd were maintaining the thumbv*m-none-eabi* targets.

We (Arm) look at a few issues in that area, for example if we're tagged or if someone points them our way. However, we are not official maintainers of the embedded targets at the moment! That said, we care about them, so will be watching this with interest. Our day-to-day focus is aarch64-unknown-linux-gnu (tier 1), for which I think we are the official maintainers (though I couldn't find a list just now).

[RalfJung]

Can confirm -- I'm having some trouble with the sparc64 ABI and I'm not sure whom to ping either.