Check tier 3 targets in CI #109099
Comments
jyn514
added
E-hard
Maybe that could be added to the bors comment that happens when tests finish? |
|
Non-blocking feedback comments will need to propagate back to PRs that were rolled up too. That will need some state tracking, so it doesn't keep nagging if a tier-3 target stays broken for a while. |
|
If we're going to do state tracking then IMO we should go all the way to the existing toolstate infrastructure, so we're not reinventing it from scratch. |
|
This was discussed two weeks ago in the library team meeting. There was a 3:2 split between a. "just add the tier 3 checks as regular CI checks, and document that manually disabling tier 3 checks is fine", and (See Zulip.) I voted for the second option, but maybe we should just try the first option to see how that works out. Maybe the kind of breakage that happens for those targets will be simple and small enough to not be an issue. (And if it does become an issue, we can change it in the future.) The first option does probably become quite annoying if we don't have a good way to run those checks manually though. So I think we need local ./x.py check would "Just Work™" when cross compiling for all tier 3 targets, and/or there needs to be a way to ask bors to run those checks, or those checks should always run on PRs directly (or at least those that touch the standard library). |
m-ou-se
removed
the
I-libs-nominated
How many (if any) targets currently supriously fail to check the parts of the stdlib they support1 if you deinit the llvm submodule? I think doing so fixes all of the failures I knew of (because we no longer try to build the compiler-rt code in compiler-builtins), but there might be some weird ones I don't know about. Obviously even if the answer is "all of them", that's not a good long term solution (it's annoying and non-obvious to have to deinit it). Footnotes
|
this should be the case once #102579 is merged |
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
stdfor tier 3 targets is very painful for t-libs:std::sysis highly platform dependent, and we have no tier 2 targets that usesys::unsupportedso it's hard to tell if it even compiles. To reduce the maintenance burden, I propose we start runningx check --target foofor 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:
src/citest runner file.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.
cc https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/.60x.20check.60.20for.20tier.203.20targets
Mentoring instructions:
x check --stage 1for each tier 3 platform.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?
cc @joboet, I think you said you were working on making it easier to cross-check targets from any host.
The text was updated successfully, but these errors were encountered: