Test that we can build a sysroot for at least all tier 2 targets?

[saethlin]

We currently cannot build sysroots for the following targets which are documented as tier 2:

i586-unknown-netbsd
x86_64-fortanix-unknown-sgx
thumbv8m.base-none-eabi
thumbv8m.main-none-eabi
thumbv8m.main-none-eabihf

There are a variety of causes for this; netbsd was added to the tier 2 list by mistake and should be tier 3, the sgx target runs into a deny lint while building backtrace that -Zbuild-std seems to evade somehow, and the thumbv8m targets emit this, which is a bug in rustc-build-sysroot (the target name get mangled by Path::file_stem):

$ cargo +nightly miri setup --target thumbv8m.base-none-eabi
Preparing a sysroot for Miri (target: thumbv8m.base-none-eabi)...
warning: Patch `rustc-std-workspace-alloc v1.99.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-alloc)` was not used in the crate graph.
Patch `rustc-std-workspace-std v1.99.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-std)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
    Checking core v0.0.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
   Compiling compiler_builtins v0.1.103
    Checking rustc-std-workspace-core v1.99.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
    Checking alloc v0.0.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc)
    Checking custom-local-sysroot v0.0.0 (/tmp/.tmpfH3QUJ)
    Finished release [optimized] target(s) in 7.85s
fatal error: failed to build sysroot: failed to read cargo out dir

Caused by:
    No such file or directory (os error 2)

I think if these targets are documented to be tier 2 "guaranteed to build", we should at least be aware if cargo-miri cannot build sysroots for them. I am of course happy to just do all these builds myself and file bugs when I find issues, but it would be neat if such a check were maintained by the team. But such a build will take some time to run; currently we have 62 tier 2 targets.

Should we have an automated check for the build status of all our tier 2 targets? If so, where?

---

Decision: Let's add a nightly workflow to build all the sysroots for tier 2 targets.

When this was opened, we had a handful of targets documented as tier 2 that don't build:

• i586-unknown-netbsd Move i586-unknown-netbsd from tier 2 to tier 3 platform support table rust#119588 moved this to tier 3 and was just deployed
• x86_64-fortanix-unknown-sgx this target gets some special treatment in backtrace that doesn't interact correctly with cfg(miri), this will be fixed by Fix deny(unused) of an unused import with SGX + Miri backtrace-rs#581 (after a sync) but that PR is blocked on Fix CI backtrace-rs#582 (also resolved by Default to --cap-lints=warn RalfJung/rustc-build-sysroot#12)
• thumbv8m.base* rustc-build-sysroot parses these wrong, should be fixed by Handle target names with dots like thumbv8m.base-none-eabi RalfJung/rustc-build-sysroot#11

[saethlin]

I'm looking into the thumbv8m.base issue RalfJung/rustc-build-sysroot#8

[RalfJung]

I think if these targets are documented to be tier 2 "guaranteed to build",

That is the rustc target policy. Miri has its own target policy, and we don't generally support tier 2 targets. I feel like supporting the tier 1 targets is keeping us sufficiently busy already.

That said, if someone wants to be our tier 2 maintainer, and deal with nightly CI failures caused by tier 2 targets, then that's fine for me. :) We could add a new CI job to run these test builds. However, 62 targets would take about an hour, so we might have to find a way to cut this down to 20-30 targets.

[saethlin]

However, 62 targets would take about an hour

I was imagining this running as a nightly job that bothers me when it fails.

Miri CI uses a runner with 2 cores right? I have a set of patches that lets you build N sysroots at once, which dramatically reduces the wall time if the builder has a handful of cores.

[RalfJung]

Miri uses the default GHA runners, no idea how many cores they have. The sysroot build will already use the regular rustc build parallelism.

I was imagining this running as a nightly job that bothers me when it fails.

That's also an option of course.

[saethlin]

The sysroot build will already use the regular rustc build parallelism.

Yes, but that is not very parallel at all. On my desktop, the average number of CPUs used during cargo +nightly miri setup is only 1.2.

I'll rig up a cron action of my own then we'll figure out if we want to move it into rust-lang.

[saethlin]

However, 62 targets would take about an hour, so we might have to find a way to cut this down to 20-30 targets.

Just running cargo +nightly miri setup for all tier 1 and tier 2 targets (which is 87 targets in total) takes almost exactly 20 minutes in GHA. That's not fast, but it's faster than our current CI time.

[RalfJung]

You can skip tier 1 targets, we should already be covering them all with our other tests. (But how can those numbers be right? We don't have 25 tier 1 targets.)

That seems completely feasible to have as another CI job then. But it can also be a nightly-only job if you prefer.

[saethlin]

(But how can those numbers be right? We don't have 25 tier 1 targets.)

We have 8 tier 1 targets, 16 tier 2 with host tools targets, and 63 tier 2 without host tools targets; so all of tier 1 and tier 2 is 87 targets.

[RalfJung]

Ah, I thought the 62 (63?) above was all tier 2, not just tier 2 without host.

[RalfJung]

@saethlin as far as I can tell, this is done?

[saethlin]

Yup, this was implemented in #3260 and a few follow-ups.