Description
NOTE: this issue does not affect the documented target tier policy of the Rust project. We reserve the right to break tier 3 targets at any time, according to the guidelines at https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html#tier-3-target-policy.
Currently, maintaining std for tier 3 targets is very painful for t-libs: std::sys is highly platform dependent, and we have no tier 2 targets that use sys::unsupported so it's hard to tell if it even compiles. To reduce the maintenance burden, I propose we start running x check --target foo for each tier 3 target, to make sure it compiles.
Note that this does not involve distributing any release artifacts; users wanting to target tier 3 platforms will still need to build rustc from source or use -Zbuild-std, but it's more likely the standard library will at least compile, even if we make no guarantees about whether it will run correctly.
We have a few options about how to test this:
- Run this on PR CI only, which acts as a janky "allow-fail" action.
- Run this in bors merges, which requires it to pass for the PR to merge. To allow the target to fail to compile, we'd manually disable it in the
src/citest runner file. - Add an allow-fail action which runs on bors merges, which doesn't block the merge but still lets us know when the target fails to build. I'm a little hesitant about this because I think it's rare people will actually look at the CI for the master branch, but maybe it's good enough.
I suggest that we wait to decide until the PR fixing these targets, since that will let us know the extent of the current breakage, and gives us a rough estimate of how much effort it will be to keep these compiling (option 2).
I'm very curious to hear @rust-lang/libs's opinion on this, particularly on the testing strategy and whether they think this will increase or decrease the maintenance burden.
Mentoring instructions:
- Add a new CI job which runs
x check --stage 1for each tier 3 platform.should be up to date; feel free to post here or on zulip if there are targets that are supported by the compiler but not in that document.rust/src/doc/rustc/src/platform-support.md
Lines 211 to 322 in 4a2de63
1a. maybe we should add a tool to keep those in sync? - Put up a PR so the CI job runs. Fix compile errors as appropriate. Some targets may not compile on all hosts (e.g. iOS will likely need a macOS host, any MSVC target will need an MSVC host); either find a way to add support or add more runners so all targets are covered. Try to avoid spending too much time on any single target; if it takes too long it's ok to skip it for now. If it ends up being an ongoing issue to support a specific target we may want to consider asking one of the target maintainers (and if they're unresponsive, or there are no maintainers, making a t-compiler MCP to remove it).
cc @joboet, I think you said you were working on making it easier to cross-check targets from any host.