Run mir-opt panic=abort tests on CI - #160200
Conversation
Otherwise we wouldn't actually exercise them on CI.
|
|
This comment has been minimized.
This comment has been minimized.
And only include the target name when rendering test metadata, to avoid including filenames in it.
|
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. |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
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