-
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
Convert run-make/coverage-reports
tests to use a custom compiletest mode
#112300
Conversation
r? @wesleywiser (rustbot has picked a reviewer for you, use r? to override) |
The part I’m least confident about is the implied |
This comment was marked as outdated.
This comment was marked as outdated.
@rustbot label +A-code-coverage |
This part looks ok to me but if @jyn514 wants to check as well, that would be awesome!
If I recall correctly, code coverage isn't supported on windows-gnu which is why the tests ignore it. |
Rebased and added some small tweaks based on feedback:
I haven't looked into the |
In light of still needing to support |
OK, I’ve fundamentally changed how the mode-implied directives work.
This is still a little bit gross, but I think it’s the best compromise for now. |
(A side-effect of the above is that it’s no longer necessary to move |
run-make/coverage-reports
tests to use a custom compiletest moderun-make/coverage-reports
tests to use a custom compiletest mode
I've now migrated all of the |
This comment has been minimized.
This comment has been minimized.
This comment was marked as outdated.
This comment was marked as outdated.
Looks like this is all working again now. |
Dealing with
So while it feels a bit weird to introduce a whole extra suite for one test, I think it ends up being the more natural solution. |
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.
This is looking pretty good to me! I noticed there used to be a mechanism in the coverage makefile to bless the tests, does --bless
still work?
// FIXME(mati865): MinGW GCC miscompiles compiler-rt profiling library but with Clang it works | ||
// properly. Since we only have GCC on the CI ignore the test for now. | ||
"ignore-windows-gnu", | ||
// FIXME(pietroalbini): this test currently does not work on cross-compiled | ||
// targets because remote-test is not capable of sending back the *.profraw | ||
// files generated by the LLVM instrumentation. | ||
"ignore-cross-compile", |
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.
Thanks for including these FIXMEs here, that will make it easier to understand in the future when they can be removed!
Yes, |
Re-enable some coverage tests on Linux These tests were originally disabled (on all platforms) in rust-lang#110393, because those changes had made them start failing on Linux for unclear reasons. I tried to re-enable them unconditionally in rust-lang#111179, since they worked locally on my Mac, but I found that they were still failing on Linux, so I gave up at that time. Later while working on rust-lang#112300 I was able to re-enable them on Windows and Mac, since those changes made it possible to add specific `ignore-` directives to individual tests. I noticed at the time that the tests actually seemed to be working again on Linux, but by that point I didn't want to risk more CI failures, so I left them disabled on Linux with an intention to re-enable them later. Now I'm going back to re-enable them on Linux too, since they seem to work fine. --- Because `run-coverage` tests are sensitive to line numbers, and `x test tidy` doesn't like leading blank lines, I've replaced the old comment/ignore with an informative comment that occupies the same number of lines.
Prior to rust-lang#114875, these tests were very sensitive to lines being added/removed, so the migration to `run-coverage` in rust-lang#112300 tried hard to avoid disturbing the existing line numbers. That resulted in some awkward reshuffling when certain comments/directives needed to be added or moved. Now that we don't have to worry about preserving line numbers, we can rearrange those comments into a more conventional layout.
The demangler was only needed by coverage tests, but those tests were migrated into their own custom test mode in rust-lang#112300. This avoids having to build the demangler just for run-make tests. It will still be built as needed by run-coverage tests or for other purposes.
The demangler was only needed by coverage tests, but those tests were migrated into their own custom test mode in rust-lang#112300. This avoids having to build the demangler just for run-make tests. It will still be built as needed by run-coverage tests or for other purposes.
Avoid unnecessary builds/rebuilds of `rust-demangler` This is a combination of two loosely-related changes: - Don't build `rust-demangler` as a dependency of `tests/run-make`, because after rust-lang#112300 none of the remaining run-make tests actually use it. (If future run-make tests ever do need the demangler, it'll be easy to add it back.) - For `tests/run-coverage`, build the demangler with the stage 0 compiler instead of the current-stage compiler. This avoids having to uselessly rebuild the demangler after modifying and rebuilding the compiler itself.
When these extra directives were ported over as part of rust-lang#112300, it made sense to introduce `iter_header_extra` and pass them in as an extra argument. But now that rust-lang#120881 has added a `mode` parameter to `iter_header` for its own purposes, it's slightly simpler to move the coverage special-case code directly into `iter_header` as well. This lets us get rid of `iter_header_extra`.
When these extra directives were ported over as part of rust-lang#112300, it made sense to introduce `iter_header_extra` and pass them in as an extra argument. But now that rust-lang#120881 has added a `mode` parameter to `iter_header` for its own purposes, it's slightly simpler to move the coverage special-case code directly into `iter_header` as well. This lets us get rid of `iter_header_extra`.
When these extra directives were ported over as part of rust-lang#112300, it made sense to introduce `iter_header_extra` and pass them in as an extra argument. But now that rust-lang#120881 has added a `mode` parameter to `iter_header` for its own purposes, it's slightly simpler to move the coverage special-case code directly into `iter_header` as well. This lets us get rid of `iter_header_extra`.
When these extra directives were ported over as part of rust-lang#112300, it made sense to introduce `iter_header_extra` and pass them in as an extra argument. But now that rust-lang#120881 has added a `mode` parameter to `iter_header` for its own purposes, it's slightly simpler to move the coverage special-case code directly into `iter_header` as well. This lets us get rid of `iter_header_extra`.
When these extra directives were ported over as part of rust-lang#112300, it made sense to introduce `iter_header_extra` and pass them in as an extra argument. But now that rust-lang#120881 has added a `mode` parameter to `iter_header` for its own purposes, it's slightly simpler to move the coverage special-case code directly into `iter_header` as well. This lets us get rid of `iter_header_extra`.
When these extra directives were ported over as part of rust-lang#112300, it made sense to introduce `iter_header_extra` and pass them in as an extra argument. But now that rust-lang#120881 has added a `mode` parameter to `iter_header` for its own purposes, it's slightly simpler to move the coverage special-case code directly into `iter_header` as well. This lets us get rid of `iter_header_extra`.
When these extra directives were ported over as part of rust-lang#112300, it made sense to introduce `iter_header_extra` and pass them in as an extra argument. But now that rust-lang#120881 has added a `mode` parameter to `iter_header` for its own purposes, it's slightly simpler to move the coverage special-case code directly into `iter_header` as well. This lets us get rid of `iter_header_extra`.
When these extra directives were ported over as part of rust-lang#112300, it made sense to introduce `iter_header_extra` and pass them in as an extra argument. But now that rust-lang#120881 has added a `mode` parameter to `iter_header` for its own purposes, it's slightly simpler to move the coverage special-case code directly into `iter_header` as well. This lets us get rid of `iter_header_extra`.
Move the extra directives for `Mode::CoverageRun` into `iter_header` When these extra directives were ported over as part of rust-lang#112300, it made sense to introduce `iter_header_extra` and pass them in as an extra argument. But now that rust-lang#120881 has added a `mode` parameter to `iter_header` for its own purposes, it's slightly simpler to move the coverage special-case code directly into `iter_header` as well. This lets us get rid of `iter_header_extra`.
Move the extra directives for `Mode::CoverageRun` into `iter_header` When these extra directives were ported over as part of rust-lang#112300, it made sense to introduce `iter_header_extra` and pass them in as an extra argument. But now that rust-lang#120881 has added a `mode` parameter to `iter_header` for its own purposes, it's slightly simpler to move the coverage special-case code directly into `iter_header` as well. This lets us get rid of `iter_header_extra`.
Rollup merge of rust-lang#121233 - Zalathar:extra-directives, r=oli-obk Move the extra directives for `Mode::CoverageRun` into `iter_header` When these extra directives were ported over as part of rust-lang#112300, it made sense to introduce `iter_header_extra` and pass them in as an extra argument. But now that rust-lang#120881 has added a `mode` parameter to `iter_header` for its own purposes, it's slightly simpler to move the coverage special-case code directly into `iter_header` as well. This lets us get rid of `iter_header_extra`.
compiletest: Unify `cmd2procres` with `run_command_to_procres` Historical context: I originally added `run_command_to_procres` in rust-lang#112300 and rust-lang#114843, because I didn't like the overly-specific failure message in `cmd2procres`, but at the time I didn't feel confident enough to change the existing code, so I just added my own similar code. Now I'm going back to remove this redundancy by eliminating `cmd2procress`, and adjusting all callers to use a slightly-tweaked `run_command_to_procres` instead.
compiletest: Unify `cmd2procres` with `run_command_to_procres` Historical context: I originally added `run_command_to_procres` in rust-lang#112300 and rust-lang#114843, because I didn't like the overly-specific failure message in `cmd2procres`, but at the time I didn't feel confident enough to change the existing code, so I just added my own similar code. Now I'm going back to remove this redundancy by eliminating `cmd2procress`, and adjusting all callers to use a slightly-tweaked `run_command_to_procres` instead.
Rollup merge of rust-lang#125753 - Zalathar:procres, r=jieyouxu compiletest: Unify `cmd2procres` with `run_command_to_procres` Historical context: I originally added `run_command_to_procres` in rust-lang#112300 and rust-lang#114843, because I didn't like the overly-specific failure message in `cmd2procres`, but at the time I didn't feel confident enough to change the existing code, so I just added my own similar code. Now I'm going back to remove this redundancy by eliminating `cmd2procress`, and adjusting all callers to use a slightly-tweaked `run_command_to_procres` instead.
I was frustrated by the fact that most of the coverage tests are glued together with makefiles and shell scripts, so I tried my hand at converting most of them over to a newly-implemented
run-coverage
mode/suite in compiletest.This
mostlyresolves #85009,though I've left a small number of the existing tests as-is because they would require more work to fix/support.I had time to go back and add support for the more troublesome tests that I had initially skipped over, so this PR now manages to completely get rid of
run-make/coverage-reports
.The patches are arranged as follows:
run-make/coverage-reports