Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
24 of 57 tasks
workingjubilee opened this issue Jul 16, 2023 · 23 comments
Open
24 of 57 tasks

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

workingjubilee opened this issue Jul 16, 2023 · 23 comments
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools A-target-specs Area: Compile-target specifications C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@workingjubilee
Copy link
Member

workingjubilee commented Jul 16, 2023

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
@workingjubilee workingjubilee added A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools A-target-specs Area: Compile-target specifications C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC labels Jul 16, 2023
@workingjubilee workingjubilee added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. I-compiler-nominated Nominated for discussion during a compiler team meeting. labels Jul 16, 2023
@thomcc
Copy link
Member

thomcc commented Jul 16, 2023

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
Copy link
Member Author

workingjubilee commented Jul 16, 2023

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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).

@apiraino apiraino removed the I-compiler-nominated Nominated for discussion during a compiler team meeting. label Aug 10, 2023
@RalfJung
Copy link
Member

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

@chrisnc
Copy link
Contributor

chrisnc commented Mar 26, 2024

I've volunteered to maintain the Armv7-R targets (all four flavors). #110377 #119102
I could contribute to maintaining the Armv*-M targets as well, but I think those have a much bigger constituency and other informal maintainers.

@jonathanpallant
Copy link
Contributor

The Embedded Devices WG had a PR cleaning up the docs and adding themselves to the Cortex-M targets, but it got lost. I'll try and open it again.

@RalfJung
Copy link
Member

Would it be worth making some sort of blogpost, saying that we need people to volunteer as maintainers here and help write the docs for the target support page, or else targets will have to be downgraded to tier 3?

@jonathanpallant
Copy link
Contributor

Seems reasonable. I gave all the Cortex-M targets to the EDWG so they can be ticked off.

@chrisnc
Copy link
Contributor

chrisnc commented Jun 12, 2024

The two "armebv7r-none-eabi(hf)? Bare Armv7-R, Big Endian" targets can be checked off as well.

@RalfJung
Copy link
Member

RalfJung commented Jun 12, 2024

Seems reasonable. I gave all the Cortex-M targets to the EDWG so they can be ticked off.

There is no target with "cortex-m" in its name or description so I'm afraid I don't know which targets you are talking about.

@jonathanpallant
Copy link
Contributor

sigh, yeah, Arm naming is fun.

  1. See https://doc.rust-lang.org/nightly/rustc/platform-support/arm-none-eabi.html - it's not on stable yet
  2. I meant Arm M-Profile Architectures (which are implemented by a series of proprietary CPU cores sold to chip designers under the Arm Cortex-M branding):

@RalfJung
Copy link
Member

Ah, I see, thanks.

It seems we do have target maintainers listed, but it's an email address, which doesn't work well with our usual github-based workflows. Any chance of having a github handle or notification group to ping?

@jonathanpallant
Copy link
Contributor

Paging @adamgreig and @therealprof for that as I'm no longer in the WG.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Aug 1, 2024
…unknown-linux-target-page, r=pietroalbini

Add target page for riscv64gc-unknown-linux-gnu

I was reading rust-lang#113739 and realized I knew most of the information necessary to create the `riscv64gc-unknown-linux-gnu` target page.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Aug 1, 2024
…unknown-linux-target-page, r=pietroalbini

Add target page for riscv64gc-unknown-linux-gnu

I was reading rust-lang#113739 and realized I knew most of the information necessary to create the `riscv64gc-unknown-linux-gnu` target page.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Aug 1, 2024
Rollup merge of rust-lang#127490 - ferrocene:hoverbear/add-riscv64gc-unknown-linux-target-page, r=pietroalbini

Add target page for riscv64gc-unknown-linux-gnu

I was reading rust-lang#113739 and realized I knew most of the information necessary to create the `riscv64gc-unknown-linux-gnu` target page.
github-actions bot pushed a commit to rust-lang/miri that referenced this issue Aug 2, 2024
…inux-target-page, r=pietroalbini

Add target page for riscv64gc-unknown-linux-gnu

I was reading rust-lang/rust#113739 and realized I knew most of the information necessary to create the `riscv64gc-unknown-linux-gnu` target page.
@workingjubilee
Copy link
Member Author

Nice, was able to mark off 15 targets as having any maintainer contacts, and a few more are en route.

@rettichschnidi
Copy link

Me (my employer) is interested in keeping armv5te-unknown-linux-gnueabi a Tier 2 platform. We should be able to invest resources (time, money), but we do not have any compiler experts. Please ping me if anyone out there is in a similar situation.

@RalfJung
Copy link
Member

@uweigand mentioned they could be pinged for s390x related questions. @uweigand would you be willing to be listed as target maintainer?

FYI the definition of that role is

A tier 2 target must have a designated team of developers (the "target maintainers") available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers.

Since we currently have 0 maintainers, I think we can make an exception to the "at least 2" rule and allow 1 to be listed (but this wouldn't be enough to get a checkbox in this issue). Maybe you know some people that would also be interested to help? :)

@uweigand
Copy link
Contributor

@uweigand mentioned they could be pinged for s390x related questions. @uweigand would you be willing to be listed as target maintainer?

Yes, I'd be happy to take on that role.

FYI the definition of that role is

A tier 2 target must have a designated team of developers (the "target maintainers") available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers.

Since we currently have 0 maintainers, I think we can make an exception to the "at least 2" rule and allow 1 to be listed (but this wouldn't be enough to get a checkbox in this issue). Maybe you know some people that would also be interested to help? :)

I'll ask around.

@RalfJung
Copy link
Member

Yes, I'd be happy to take on that role.

Awesome. :)

@workingjubilee do you know how the paperwork for that works? :D

@workingjubilee
Copy link
Member Author

workingjubilee commented Oct 30, 2024

@uweigand All that's required is to submit a PR adding the target's platform support document and noting that you do in fact assent to be the target maintainer in the PR description. There is a template here: https://github.com/rust-lang/rust/blob/759e07f063fb8e6306ff1bdaeb70af56a878b415/src/doc/rustc/src/platform-support/TEMPLATE.md

Make sure it's linked from the actual platform support page: https://github.com/rust-lang/rust/blob/759e07f063fb8e6306ff1bdaeb70af56a878b415/src/doc/rustc/src/platform-support.md

And listed in the summary: https://github.com/rust-lang/rust/blob/759e07f063fb8e6306ff1bdaeb70af56a878b415/src/doc/rustc/src/SUMMARY.md

@uweigand
Copy link
Contributor

@uweigand All that's required is to submit a PR adding the target's platform support document and noting that you do in fact assent to be the target maintainer in the PR description.

I've now opened #133186, thanks!

@RalfJung
Copy link
Member

RalfJung commented Dec 4, 2024

According to rust-lang/compiler-team#812, @psumbera has been our "de facto target maintainer" for Solaris targets. @psumbera , would you be okay with documenting that officially, so that when a Solaris issue comes up, compiler team members can find you in the target list and ping you?

Nominally we need a team of 2 target maintainers for tier 2 targets, but given that currently we have 0 listed, having 1 would be a good improvement. :) But if you happen to know anyone else who might be willing to help with this, that'd be even better. :D

EDIT: Ah, the PR at #133293 is already up, great! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools A-target-specs Area: Compile-target specifications C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants