-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Update CoverageMappingFormat to Version6 #90047
Conversation
cc: @tmandry @wesleywiser |
d0ec389
to
d8544b9
Compare
Q: should I keep backwards compat with version 4 / llvm 11? |
It seems like it will be really easy to keep it compatible with LLVM 11, and as long as rustc still supports LLVM 11 (I assume it does still), there is probably no reason not to maintain compatibility as long as you can, IMO. (My opinion is based on the believe that this requires only a couple of additional lines of code, which appears to be true.) I suspect branch coverage (if it's even needed... see my Zulip comment) will require some time to implement and test, and if so, it may be helpful to LLVM 11 users for some time to come. Is it critical? Probably not, but I think it's worth supporting, given these assumptions.
Correct me if I'm wrong, but branch coverage only requires LLVM 12, right?
Hm... I was assuming there are still tests using older versions of LLVM, for every major version supported by Rustc. Isn't this the case? If rustc doesn't officially support LLVM 11 anymore (or when they don't) then we don't need to support it any longer in coverage either. I'm just requesting we support it as long as rustc officially does. |
LLVM 11 is not going away soon, support for LLVM 10 is being dropped right now: #90062 |
@Swatinem - I will be OOO, mostly without a laptop, for 3 weeks, after today. I'd like to nominate @tmandry or @wesleywiser to review and approve this when you are ready. Thanks for your contributions!! Also, since there is now a proposal to stablize the r? @tmandry (this probably doesn't work while the PR is in Draft mode) |
@richkadel thanks for your feedback so far! I think I will pause this at least until LLVM 11 and stabilization of the flag happens, in the meanwhile the feedback has guided me in another direction I want to explore. |
+1, supporting versions 4 & 5 sounds like it will be pretty easy so I think we should definitely do that. If that isn't true, we can consider dropping support for older versions but having the widest range of support for older LLVM versions would be best. |
FYI we might end up bumping minimal LLVM to 12: #90175, that will allow to simplify this PR. |
☔ The latest upstream changes (presumably #90175) made this pull request unmergeable. Please resolve the merge conflicts. |
@Swatinem LLVM 12 is the minimum now. |
d8544b9
to
52c205a
Compare
Updated the PR and rebased on latest r? @tmandry |
/// and published in Rust's November 2020 fork of LLVM. This version is supported by the LLVM | ||
/// This Coverage Map complies with Coverage Mapping Format version 6 (zero-based encoded as 5), | ||
/// as defined at [LLVM Code Coverage Mapping Format](https://github.com/rust-lang/llvm-project/blob/rustc/13.0-2021-09-30/llvm/docs/CoverageMappingFormat.rst#llvm-code-coverage-mapping-format) | ||
/// and published in Rust's September 2021 fork of LLVM. This version is supported by the LLVM |
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.
nit: We might consider removing this date from the comment. I'm not sure it really adds any value.
@bors r+ |
📌 Commit 52c205a34fa958f1a5b74c8016e62c21c4d7a08d has been approved by |
⌛ Testing commit 52c205a34fa958f1a5b74c8016e62c21c4d7a08d with merge 6fe98430601dc3b277da8938870e10b14f132e3f... |
💔 Test failed - checks-actions |
This comment has been minimized.
This comment has been minimized.
52c205a
to
99b7e9c
Compare
Removed the date (and corrected the comment to say that we output version 5) as suggested by @wesleywiser and rebased on recent master. I’m a bit baffled by the CI failure. I can’t reproduce that on my Windows, will try with Linux tomorrow. |
@Swatinem are you still available to investigate the CI failure? |
Haven’t had time yet to investigate, pretty much saturated with other things right now. |
Version 5 adds Branch Regions which are a prerequisite for branch coverage. Version 6 can use the zeroth filename as prefix for other relative files.
99b7e9c
to
90ee252
Compare
I could not repro that CI error, neither on my local Linux machine nor on the docker image that I believe corresponds to where that error occurred. I think it was an intermittent error that may not happen again? |
This commit augments Swatinem's initial commit in uncommitted PR rust-lang#90047, which was a great starting point, but did not fully support LLVM Coverage Mapping Format version 6. Version 6 requires adding the compilation directory when file paths are relative, and since Rustc coverage maps use relative paths, we should add the expected compilation directory entry. Note, however, that with the compilation directory, coverage reports from `llvm-cov show` can now report file names (when the report includes more than one file) with the full absolute path to the file. This would be a problem for test results, but the workaround (for the rust coverage tests) is to include an additional `llvm-cov show` parameter: `--compilation-dir=.`
… r=tmandry Add support for LLVM coverage mapping format versions 5 and 6 This PR cherry-pick's Swatinem's initial commit in unsubmitted PR rust-lang#90047. My additional commit augments Swatinem's great starting point, but adds full support for LLVM Coverage Mapping Format version 6, conditionally, if compiling with LLVM 13. Version 6 requires adding the compilation directory when file paths are relative, and since Rustc coverage maps use relative paths, we should add the expected compilation directory entry. Note, however, that with the compilation directory, coverage reports from `llvm-cov show` can now report file names (when the report includes more than one file) with the full absolute path to the file. This would be a problem for test results, but the workaround (for the rust coverage tests) is to include an additional `llvm-cov show` parameter: `--compilation-dir=.`
… r=tmandry Add support for LLVM coverage mapping format versions 5 and 6 This PR cherry-pick's Swatinem's initial commit in unsubmitted PR rust-lang#90047. My additional commit augments Swatinem's great starting point, but adds full support for LLVM Coverage Mapping Format version 6, conditionally, if compiling with LLVM 13. Version 6 requires adding the compilation directory when file paths are relative, and since Rustc coverage maps use relative paths, we should add the expected compilation directory entry. Note, however, that with the compilation directory, coverage reports from `llvm-cov show` can now report file names (when the report includes more than one file) with the full absolute path to the file. This would be a problem for test results, but the workaround (for the rust coverage tests) is to include an additional `llvm-cov show` parameter: `--compilation-dir=.`
… r=tmandry Add support for LLVM coverage mapping format versions 5 and 6 This PR cherry-pick's Swatinem's initial commit in unsubmitted PR rust-lang#90047. My additional commit augments Swatinem's great starting point, but adds full support for LLVM Coverage Mapping Format version 6, conditionally, if compiling with LLVM 13. Version 6 requires adding the compilation directory when file paths are relative, and since Rustc coverage maps use relative paths, we should add the expected compilation directory entry. Note, however, that with the compilation directory, coverage reports from `llvm-cov show` can now report file names (when the report includes more than one file) with the full absolute path to the file. This would be a problem for test results, but the workaround (for the rust coverage tests) is to include an additional `llvm-cov show` parameter: `--compilation-dir=.`
… r=tmandry Add support for LLVM coverage mapping format versions 5 and 6 This PR cherry-pick's Swatinem's initial commit in unsubmitted PR rust-lang#90047. My additional commit augments Swatinem's great starting point, but adds full support for LLVM Coverage Mapping Format version 6, conditionally, if compiling with LLVM 13. Version 6 requires adding the compilation directory when file paths are relative, and since Rustc coverage maps use relative paths, we should add the expected compilation directory entry. Note, however, that with the compilation directory, coverage reports from `llvm-cov show` can now report file names (when the report includes more than one file) with the full absolute path to the file. This would be a problem for test results, but the workaround (for the rust coverage tests) is to include an additional `llvm-cov show` parameter: `--compilation-dir=.`
Closing in favor of #91207 which subsumes this commit |
Version 5 adds Branch Regions which are a prerequisite for branch coverage (#79649) which I plan to take a look at next.
Version 6 can use the zeroth filename as prefix for other relative files.