Run mir-opt panic=abort tests on CI - #160200
Conversation
|
|
This comment has been minimized.
This comment has been minimized.
|
cf. #154607 |
| let panic_abort_target = builder | ||
| .ensure(MirOptPanicAbortSyntheticTarget { compiler: self.compiler, base: self.target }); | ||
| run(panic_abort_target); |
There was a problem hiding this comment.
Question: hm, could we have this show up in a step resolution snapshot?
There was a problem hiding this comment.
We have it shown in the step snapshot tests. Do you want to separate it so that instead of running mir-opt directly within the step, we generate two steps, one without mir-opt and another with mir-opt? And when blessing, we move the generation of additional steps to make_run?
|
I don't know nearly enough about bootstrap to review this.^^ |
| // Now also run the tests for the host with panic=abort | ||
| let panic_abort_target = builder | ||
| .ensure(MirOptPanicAbortSyntheticTarget { compiler: self.compiler, base: self.target }); | ||
| run(panic_abort_target); |
There was a problem hiding this comment.
This will be redundant with --bless I think?
mir-opt --bless already takes very long due to all the sysroots it is building, I'd prefer it not to become even slower.
There was a problem hiding this comment.
It is only redundant if the host target matches the hardcoded targets we have below. I can add an if condition to skip them if they match the host target.
That being said, if the stdlib it built, re-running the tests again should be very fast, they will just be ignored.
There was a problem hiding this comment.
It is always redundant. There are only 4 actually distinct configurations, so running more than 4 targets on --bless is redundant.
There was a problem hiding this comment.
I see, so the target doesn't really matter, the only thing that matters is bitwidth and the panic strategy? Yeah, in that case I will try to optimize it to always run 2 targets when not blessing, and 4 targets when blessing.
There was a problem hiding this comment.
Yeah.
When checking it's good to check the actual self.target to ensure CI covers them all. But in principle only the bitwidth and panic strategy should matter.
|
Cc @saethlin |
|
The existing behavior of
And only run the first two steps for non-bless mode. That'd be nice. |
This comment has been minimized.
This comment has been minimized.
But when we do the check, we should test all 4 combinations, right? Otherwise we could get back into the same problem, where some of the combinations are not checked on CI, and thus bless becomes "dirty". |
|
We are running mir-opt tests on all tier 1 targets, right? So 32bit and 64bit are both covered.
|
|
Ah, I see, makes sense. Thanks. |
And only include the target name when rendering test metadata, to avoid including filenames in it.
… of targets to check
a65622e to
b63868d
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
Ok, I refactored the whole thing. Now when checking, we run the current target, and then the current target with the "inverted" panic strategy. And when blessing, we run the current target + four fixed targets, as before (there was a comment saying that running also the current target when blessing is desired). It is now possible to create synthetic targets with both panic abort/unwind strategies, and the generated miropt test steps are now created as separate step instances, which means that they will be more explicit tin the step trace, and they will also be properly cached. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
| // selection covers all our tier 1 operating systems and architectures using only tier | ||
| // 1 targets. | ||
| // We also include the host target, since some tests use very specific `only` clauses | ||
| // that are not covered by the target set below. |
There was a problem hiding this comment.
| // that are not covered by the target set below. | |
| // that are not covered by the target set below. | |
| // FIXME: In the future it'd be great to skip one of the other 4 targets if its | |
| // bit-width and panic combination is already covered by the host. |
There was a problem hiding this comment.
I implemented the optimization right away.
This comment has been minimized.
This comment has been minimized.
560add1 to
0ce420f
Compare
|
The job Click to see the possible cause of the failure (guessed by this bot) |
View all comments
Context: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Blessing.20mir-opt.20on.20a.20clean.20checkout.20produces.20a.20diff/near/613465816
It looks like we didn't run them on CI (ever? lol).
r? @RalfJung