-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mir-opt tests: run current target on --bless; enable --keep-stage-std #122257
Conversation
r? @clubby789 rustbot has assigned @clubby789. Use r? to explicitly pick a reviewer |
@bors r+ |
…lubby789 mir-opt tests: don't run a different set on --bless; enable --keep-stage-std Currently, `./x.py test tests/mir-opt` runs only the tests for the current target, and `./x.py test tests/mir-opt --bless` runs tests for a representative set of targets. I find this confusing and not what I want: for one I never run tests without `--bless` because I prefer to look at a git diff. What I however like to do is pass `--keep-stage-std` when I'm working on the compiler; this doesn't work today with `--bless` because it tries a bunch of targets for which I don't have a built std. In this PR, I make it so `./x.py test tests/mir-opt` runs the same set of tests regardless of `--bless`. By default it runs a representative sample of targets, and if `--keep-stage-std` is set it only runs tests for the current target.
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#121573 (unix_sigpipe: Add test for SIGPIPE disposition in child processes) - rust-lang#121754 ([bootstrap] Move the `split-debuginfo` setting to the per-target section) - rust-lang#122205 (ensure that sysroot is properly set for cross-targets) - rust-lang#122257 (mir-opt tests: don't run a different set on --bless; enable --keep-stage-std) - rust-lang#122272 (Subtree update of `rust-analyzer`) Failed merges: - rust-lang#122108 (Add `target.*.runner` configuration for targets) r? `@ghost` `@rustbot` modify labels: rollup
Having seen #122292, I'm not sure this is a good idea anymore. For one, in CI we only want to run the test for the current target (I assume that was the original intent of the @bors r- |
As you noted, this decreases test coverage. So I don't think it is a good idea. I think it is important that Blessing with different targets is needed since MIR differs a lot between panic=abort and panic=unwind. So if you actually want to bless tests then you most likely do want to do it for more than just your host target. It is never useful to bless just the host target. |
@@ -1568,6 +1568,7 @@ impl Step for MirOpt { | |||
run(panic_abort_target); | |||
} | |||
} else { | |||
// If we're keeping a std stage, only run tests for this target. | |||
run(self.target); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My proposed patch would be to simply move this to before the if
.
Alternatively we could enact a policy saying that only-x86_64
is not allowed in mir-opt, and generally making sure that the set of targets in the bless list above is covering all mir-opt tests. That would require tool support however.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to have more targets here. At least have all targets that are run in CI
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would take forever though
Yeah ok, there are two changes then:
Let's keep the |
047e17d
to
1043209
Compare
Oh, we can keep several |
1043209
to
b6ea60f
Compare
Alright, I'll make a different PR for your fix |
@@ -1549,6 +1549,8 @@ impl Step for MirOpt { | |||
}) | |||
}; | |||
|
|||
run(self.target); | |||
|
|||
if builder.config.cmd.bless() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if builder.config.cmd.bless() { | |
// Run more targets with `--bless`. But we always run the host target first, since some | |
// tests use very specific `only` clauses that are not covered by the target set below. | |
if builder.config.cmd.bless() { |
Currently,
./x.py test tests/mir-opt
runs only the tests for the current target, and./x.py test tests/mir-opt --bless
runs tests for a representative set of targets.I find this confusing and not what I want: for one I never run tests without
--bless
because I prefer to look at a git diff. What I however like to do is pass--keep-stage-std
when I'm working on the compiler; this doesn't work today with--bless
because it tries a bunch of targets for which I don't have a built std.In this PR, I make it so
./x.py test tests/mir-opt
runs the same set of tests regardless of--bless
. By default it runs a representative sample of targets, and if--keep-stage-std
is set it only runs tests for the current target.Fixes #122292