target tier policy compliance #116004

davidtwco · 2023-09-20T14:06:20Z

This pull request makes a lot of changes to our targets (nothing that affects their behaviour!) to start making sure that they all comply with our target tier policy.

I've done a quick check to see if each target complies with our policies which don't require documentation (no onerous licensing, etc).
Each target now has a platform support page, most of these are newly added and just have "Missing!" on them a lot. I need your help to populate these!
Each target now has an assembly test in tests/assembly/targets, it's the same simple code in each test, it just confirms that we can in fact produce something resembling assembly given the target triple.
I've moved some things around in compiler/rustc_target/spec. Previously, we had the base targets (e.g. windows_msvc_base, which all the Windows MSVC targets would inherit from) in the same directory as the targets themselves. I've moved these to compiler/rustc_target/spec/base. This change makes the implementation of a new tidy lint easier.
Similarly, in our platform support index, we had pages like windows_msvc.md which would be linked to by all of the Windows MSVC targets. I've changed it so that every target has its own page, and when multiple targets were linking to one page, then only one of those targets has the content of that previous page, and the others symlink to that target. Likewise, this change makes the implementation of a new tidy lint easier.
I've introduced a tidy lint which checks that for every target file in compiler/rustc_target/spec, there exists a test with the same filename in tests/assembly/target and platform support documentation in src/doc/rustc/src/platform-support/. After all of my changes, this tidy lint isn't reporting any errors.

With respect to specific targets:

I've technically added i386-unknown-linux-gnu and i486-unknown-linux-gnu. Originally added in Added support for i386-unknown-linux-gnu and i486-unknown-linux-gnu #80662, these targets never actually got added to the compiler, the target definitions were there but the compiler never knew about them.
NetBSD’s platform support page had some targets listed that no longer existed or had different names (e.g. amd64 to x86_64 and mipsel removed) - I’ve updated it to reflect the targets which exist.
i686-pc-windows-msvc and x86_64-pc-windows-msvc were listed as both tier 1 and tier 3, depending on the version of Windows, which seems like a misuse of the tier system, so I've removed them from tier 3. Support for different versions of the target can be documented in the platform support page.
powerpc-unknown-openbsd wasn't listed in OpenBSD's platform support page like every other OpenBSD target - I've added it but maybe I shouldn't have.

Tier 1 w/ Host Tools

aarch64-unknown-linux-gnu
- Incomplete platform support document
i686-pc-windows-gnu
- Incomplete platform support document
i686-pc-windows-msvc
- Incomplete platform support document
i686-unknown-linux-gnu
- Incomplete platform support document
x86_64-apple-darwin
- Incomplete platform support document
x86_64-pc-windows-gnu
- Incomplete platform support document
x86_64-pc-windows-msvc
- Incomplete platform support document
x86_64-unknown-linux-gnu
- Incomplete platform support document

Tier 2 w/ Host Tools

Tier 2

Tier 3

I intend to go through each of these to try and fix them, but I encourage all contributions helping out!

Please help! If you're interested in being responsible for one of these targets, send me a PR to this PR's branch, adding yourself to the target maintainer list and complete the platform support document.
I'll do plenty of squashing to keep the number of commits managable but I'll preserve any contributions in co-authorship.
Feel free to make multiple targets point to the same platform support document if it makes sense to do. I did this when I could identify that targets were added together, or where they already were.

cc rust-lang/rust-forge#255
r? @wesleywiser

Update target tier policy to require that targets be able to produce object code with a supported backend. Signed-off-by: David Wood <david@davidtw.co>

Signed-off-by: David Wood <david@davidtw.co>

wesleywiser · 2023-09-20T23:54:12Z

The *-uwp targets currently have no one maintaining them as far as I'm aware

That matches my understanding as well.

I believe thumbv7a (arm32) will not be supported by Microsoft going forward. In any case they should probably have dedicated maintainers, how to test, etc.

That's correct and dotnet is also dropping support for thumbv7a/arm32 Windows in the next major version.

petrochenkov · 2023-09-21T04:21:28Z

@davidtwco
Could you move the infrastructural changes in rustc_target (moving subdirectories, etc) to a separate PR (while also considering #116004 (comment))?
I'll then review and merge it sooner, before info for all the individual targets is populated.

RalfJung · 2023-09-21T10:06:56Z

tests/assembly/targets/aarch64_be_unknown_netbsd.rs

@@ -0,0 +1,17 @@
+// assembly-output: emit-asm
+// compile-flags: --target aarch64_be-unknown-netbsd
+// needs-llvm-components: aarch64


How identical are these tests? Does the assembly test suite support revisions? Would it be worth having a single test with a revision for each target, instead of tons of files?

bors · 2023-09-21T22:10:14Z

☔ The latest upstream changes (presumably #115230) made this pull request unmergeable. Please resolve the merge conflicts.

RalfJung · 2023-09-22T05:26:50Z

tests/assembly/targets/s390x_unknown_linux_gnu.rs

@@ -0,0 +1,17 @@
+// assembly-output: emit-asm
+// compile-flags: --target s390x-unknown-linux-gnu
+// needs-llvm-components: s390x


@cuviper are you saying this should say systemz?

Yep, that's what the component is named in LLVM.

ehuss · 2023-09-22T18:31:57Z

I'm a little concerned about the proliferation of over 200 new chapters in the rustc book. It can overwhelm the navigation, and generally a be a bit too much. Would it be possible to consider the following changes to mitigate that?

Don't split targets that share a common file, and retain the * groupings that existed before.
Or, use sub-chapters with folding to hide the huge list. For example, it could have separate sub-chapters like "Windows", "Apple", "Wasm", "Linux", "Bare", "Other". Or the sub-chapters could be the tier levels. Or just a single sub-chapter ("Platforms") under the policy chapters. Then use folding (in book.toml) so that they don't all appear at once:

[output.html.fold]
enable = true
level = 1

ehuss · 2023-09-22T18:29:17Z

src/doc/rustc/src/platform-support/arm_unknown_linux_musleabi.md

+**Tier: 2**
+
+| Target                         | Tier                   | Description                                     |
+| ============================== | ====================== | =============================================== |


All of these tables do not render correctly. I believe the header separator must use ----, not ====.

RalfJung · 2023-09-23T06:12:25Z

There will also be a lot of redundancy across these target pages, e.g. once we start documenting things that are wrong with particular targets (such as #113053). However, for those kinds of problems, grouping the pages by OS wouldn't be helpful -- we'd want them grouped by architecture.

ecnelises · 2023-10-09T06:26:23Z

Is it really necessary to list every triple in platform-support document?

Triple consists of arch-variant-vendor-os-abi, variant and abi are optional, single vendor seldom differentiates targets, maintainer or build info of some OS for all architectures do not make sense. So arch-os is usually enough, and details can be explained in full triple docs if necessary.

he32 · 2023-10-21T11:13:25Z

* NetBSD’s platform support page had some targets listed that no longer existed or had different names (e.g. `amd64` to `x86_64` and `mipsel` removed) - I’ve updated it to reflect the targets which exist.

Uh-oh. I care about this. It's evident that I need to get off my butt and upstream the mipsel bits, they currently live as patches in our pkgsrc package.

* [ ]  `x86_64-unknown-netbsd`
  
  * NetBSD's platform support page had some targets listed that no longer existed or had different names (e.g. `amd64` -> `x86_64` and `mipsel` removed) - I've updated it to reflect the targets which exist
  * This target otherwise complies, it's only marked as incomplete so the above gets a look.

Ditto, I'll take a look. "No longer existed" for mipsel is rather "exists elsewhere, not yet upstreamed"; will make a push for having those bits applied "here" instead.

workingjubilee · 2023-10-29T08:01:14Z

tests/assembly/targets/asmjs_unknown_emscripten.rs

+// assembly-output: emit-asm
+// compile-flags: --target asmjs-unknown-emscripten
+// needs-llvm-components: webassembly
+
+#![feature(no_core, lang_items)]
+#![no_std]
+#![no_core]
+#![crate_type = "lib"]
+
+#[lang = "sized"]
+trait Sized {}
+
+pub fn test() -> u8 {
+    42
+}
+
+// CHECK: .section


Being able to write an assembly test here does not mean that this target generates the correct code: the object code this target currently generates is instead wasm, which allows it to pass the "does it generate assembly" question, but will not actually be asm.js (and makes the target redundant with wasm32-unknown-emscripten).

Nilstrieb · 2023-10-29T10:36:24Z

In addition to specific targets, it may be useful to have maintainers for specific architectures for issues like #117347. Really, maybe our target maintainership should be a bit more two-dimensional? Maintainers for arches and maintainers for OS/platform. This would significantly reduce the amount of necessary files and would be more useful in practice I think. There are of course exceptions like consoles that are very "single target" focused, but for something like powerpc-unknown-openbsd, it's probably more useful to have "the powerpc people" and "the openbsd people" who will then be consulted depending on the specifics of the kind of problem with the target. The actual "owner" of the target will probably be the OS people, but with this we could reduce the huge list by just listing the target as "openbsd", and having a different table somewhere for the arch specific maintainers for arch questions.

he32 · 2023-10-30T18:18:14Z

I have taken steps to retain the mipsel-unknown-netbsd target, ref. #117356.

RalfJung · 2023-11-02T16:22:16Z

In addition to specific targets, it may be useful to have maintainers for specific architectures for issues like #117347. Really, maybe our target maintainership should be a bit more two-dimensional? Maintainers for arches and maintainers for OS/platform.

It would also be great to have an easier way to ping them. Right now it is quite cumbersome. We could maybe utilize ping groups for that?

davidtwco · 2023-11-08T02:10:12Z

I got busy and let this bitrot a little too much, so I'm going to close this PR and take a different approach taking into account a lot of the feedback here. If you sent me information about your targets then I've kept track of that and will make use of it. If you have more feedback on this then feel free to continue to comment here or message me on Zulip.

…=petrochenkov target: move base and target specifications Follow-up to rust-lang#116004. In anticipation of later PRs where we'll want to add tidy checks to ensure that, for each target, we have a test or a platform support document or something like that, this PR moves target specifications into a directory on their own so that we can just list the files in this directory to get a list of all targets. - Base specifications are moved to `rustc_target::spec::base`. - Target specifications are moved to `rustc_target::spec::targets`. - All the other source files containing types used in the target specs remain in `rustc_target::spec`. - `rustc_target/src/spec/abi.rs` is moved to `rustc_target/src/spec/abi/mod.rs` (where there was already a `tests.rs`) for uniformity. r? `@petrochenkov`

…=petrochenkov target: move base and target specifications Follow-up to rust-lang#116004. In anticipation of later PRs where we'll want to add tidy checks to ensure that, for each target, we have a test or a platform support document or something like that, this PR moves target specifications into a directory on their own so that we can just list the files in this directory to get a list of all targets. - Base specifications are moved to `rustc_target::spec::base`. - Target specifications are moved to `rustc_target::spec::targets`. - All the other source files containing types used in the target specs remain in `rustc_target::spec`. - `rustc_target/src/spec/abi.rs` is moved to `rustc_target/src/spec/abi/mod.rs` (where there was already a `tests.rs`) for uniformity. r? ``@petrochenkov``

Rollup merge of rust-lang#117702 - davidtwco:target-tier-refactors, r=petrochenkov target: move base and target specifications Follow-up to rust-lang#116004. In anticipation of later PRs where we'll want to add tidy checks to ensure that, for each target, we have a test or a platform support document or something like that, this PR moves target specifications into a directory on their own so that we can just list the files in this directory to get a list of all targets. - Base specifications are moved to `rustc_target::spec::base`. - Target specifications are moved to `rustc_target::spec::targets`. - All the other source files containing types used in the target specs remain in `rustc_target::spec`. - `rustc_target/src/spec/abi.rs` is moved to `rustc_target/src/spec/abi/mod.rs` (where there was already a `tests.rs`) for uniformity. r? ``@petrochenkov``

davidtwco added 30 commits September 20, 2023 14:28

doc: target tier policy with compiler-team#655

5e548e1

Update target tier policy to require that targets be able to produce object code with a supported backend. Signed-off-by: David Wood <david@davidtw.co>

target compliance: x86_64h-apple-darwin

cc28971

Signed-off-by: David Wood <david@davidtw.co>

target compliance: *-wrs-vxworks

16652f0

Signed-off-by: David Wood <david@davidtw.co>

target compliance: *-unknown-openbsd

ec2207a

Signed-off-by: David Wood <david@davidtw.co>

target compliance: *-unknown-linux-ohos

9ffe261

Signed-off-by: David Wood <david@davidtw.co>

target compliance: x86_64-unknown-l4re-uclibc

61750e9

Signed-off-by: David Wood <david@davidtw.co>

target compliance: *-unknown-hermit

e9f3db4

Signed-off-by: David Wood <david@davidtw.co>

target compliance: *-unknown-haiku

eb644c8

Signed-off-by: David Wood <david@davidtw.co>

target compliance: x86_64-unknown-dragonfly

6ad7f0f

Signed-off-by: David Wood <david@davidtw.co>

target compliance: x86_64-unikraft-linux-musl

24016d2

Signed-off-by: David Wood <david@davidtw.co>

target compliance: *-uwp-windows-{msvc,gnu}

2cb4531

Signed-off-by: David Wood <david@davidtw.co>

target compliance: x86_64-sun-solaris

ceea4fa

Signed-off-by: David Wood <david@davidtw.co>

target compliance: drop windows xp in tier 3

1f8ce49

Signed-off-by: David Wood <david@davidtw.co>

target compliance: x86_64-pc-windows-gnullvm

be2b697

Signed-off-by: David Wood <david@davidtw.co>

target compliance: x86_64-pc-nto-qnx710

28109b5

Signed-off-by: David Wood <david@davidtw.co>

target compliance: *-apple-watchos{,-*}

85ce178

Signed-off-by: David Wood <david@davidtw.co>

target compliance: *-apple-tvos

1947656

Signed-off-by: David Wood <david@davidtw.co>

target compliance: *-apple-ios-macabi

5076fe7

Signed-off-by: David Wood <david@davidtw.co>

target compliance: wasm64-unknown-unknown

44c6fdf

Signed-off-by: David Wood <david@davidtw.co>

target compliance: wasm32-wasi-preview1-threads

92e5322

Signed-off-by: David Wood <david@davidtw.co>

target compliance: thumbv7neon-unknown-linux-musleabihf

8169ca1

Signed-off-by: David Wood <david@davidtw.co>

target compliance: thumbv7a-pc-windows-msvc

23e54d0

Signed-off-by: David Wood <david@davidtw.co>

target compliance: {arm,thumb}v5te-none-eabi

29b2ca8

Signed-off-by: David Wood <david@davidtw.co>

target compliance: {arm,thumb}v4t-none-eabi

4b49b81

Signed-off-by: David Wood <david@davidtw.co>

target compliance: sparc-unknown-none-elf

e228da1

Signed-off-by: David Wood <david@davidtw.co>

target compliance: sparc-unknown-linux-gnu

f7f9e85

Signed-off-by: David Wood <david@davidtw.co>

target compliance: s390x-unknown-linux-musl

9f7929c

Signed-off-by: David Wood <david@davidtw.co>

target compliance: riscv64-linux-android

13e23bb

Signed-off-by: David Wood <david@davidtw.co>

target compliance: netbsd

1a49c26

Signed-off-by: David Wood <david@davidtw.co>

target compliance: fuchsia

d034d66

Signed-off-by: David Wood <david@davidtw.co>

petrochenkov added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Sep 21, 2023

RalfJung reviewed Sep 21, 2023

View reviewed changes

RalfJung mentioned this pull request Sep 21, 2023

riscv64gc-unknown-linux-gnu extern "C" ABI violates repr(transparent) on unions #115481

Closed

RalfJung mentioned this pull request Sep 22, 2023

run abi/compatibility test against a whole bunch of targets #116030

Merged

RalfJung reviewed Sep 22, 2023

View reviewed changes

ehuss reviewed Sep 22, 2023

View reviewed changes

RalfJung mentioned this pull request Sep 23, 2023

What guarantees are provided about whether the reference/stdlib docs are valid on target architectures? rust-lang/unsafe-code-guidelines#461

Open

jackh726 mentioned this pull request Oct 4, 2023

Add arm64e-apple-ios & arm64e-apple-darwin targets #115526

Merged

adamgreig mentioned this pull request Oct 8, 2023

Maintainers for embedded targets rust-embedded/wg#704

Open

5 tasks

ecnelises mentioned this pull request Oct 9, 2023

Add AIX platform support document #114316

Merged

jacobbramley mentioned this pull request Oct 13, 2023

Update and split "arm" team. rust-lang/team#1094

Merged

ehuss mentioned this pull request Oct 26, 2023

Document tier 3 platform support rust-lang/rust-forge#255

Closed

41 tasks

workingjubilee reviewed Oct 29, 2023

View reviewed changes

davidtwco closed this Nov 8, 2023

davidtwco mentioned this pull request Nov 8, 2023

target: move base and target specifications #117702

Merged

adamgreig mentioned this pull request Feb 3, 2024

doc/rustc: fill out target platform-support docs davidtwco/rust#1

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

target tier policy compliance #116004

target tier policy compliance #116004

davidtwco commented Sep 20, 2023 •

edited

wesleywiser commented Sep 20, 2023

petrochenkov commented Sep 21, 2023

RalfJung Sep 21, 2023

bors commented Sep 21, 2023

RalfJung Sep 22, 2023

cuviper Sep 22, 2023

ehuss commented Sep 22, 2023

ehuss Sep 22, 2023 •

edited

RalfJung commented Sep 23, 2023

ecnelises commented Oct 9, 2023

he32 commented Oct 21, 2023

workingjubilee Oct 29, 2023

Nilstrieb commented Oct 29, 2023 •

edited

he32 commented Oct 30, 2023

RalfJung commented Nov 2, 2023

davidtwco commented Nov 8, 2023

target tier policy compliance #116004

target tier policy compliance #116004

Conversation

davidtwco commented Sep 20, 2023 • edited

Tier 1 w/ Host Tools

Tier 2 w/ Host Tools

Tier 2

Tier 3

wesleywiser commented Sep 20, 2023

petrochenkov commented Sep 21, 2023

RalfJung Sep 21, 2023

Choose a reason for hiding this comment

bors commented Sep 21, 2023

RalfJung Sep 22, 2023

Choose a reason for hiding this comment

cuviper Sep 22, 2023

Choose a reason for hiding this comment

ehuss commented Sep 22, 2023

ehuss Sep 22, 2023 • edited

Choose a reason for hiding this comment

RalfJung commented Sep 23, 2023

ecnelises commented Oct 9, 2023

he32 commented Oct 21, 2023

workingjubilee Oct 29, 2023

Choose a reason for hiding this comment

Nilstrieb commented Oct 29, 2023 • edited

he32 commented Oct 30, 2023

RalfJung commented Nov 2, 2023

davidtwco commented Nov 8, 2023

davidtwco commented Sep 20, 2023 •

edited

ehuss Sep 22, 2023 •

edited

Nilstrieb commented Oct 29, 2023 •

edited