Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

Swatinem
Copy link
Contributor

@Swatinem Swatinem commented Oct 19, 2021

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.

@richkadel
Copy link
Contributor

cc: @tmandry @wesleywiser

@Swatinem Swatinem force-pushed the bump-coverage-version branch from d0ec389 to d8544b9 Compare October 19, 2021 19:07
@Swatinem Swatinem changed the title Update CoverageMappingFormat to Version5 Update CoverageMappingFormat to Version6 Oct 19, 2021
@Swatinem
Copy link
Contributor Author

Q: should I keep backwards compat with version 4 / llvm 11?
I think that later on I will update the tests to actually use the branch coverage output, at which point the tests would require llvm 13. Do we want to have support down to 11 although that might be untested?

@richkadel
Copy link
Contributor

Q: should I keep backwards compat with version 4 / llvm 11? I think that later on I will update the tests to actually use the branch coverage output, ...

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.

at which point the tests would require llvm 13.

Correct me if I'm wrong, but branch coverage only requires LLVM 12, right?

Do we want to have support down to 11 although that might be untested?

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.

@Swatinem Swatinem marked this pull request as draft October 20, 2021 15:58
@mati865
Copy link
Contributor

mati865 commented Oct 20, 2021

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),

LLVM 11 is not going away soon, support for LLVM 10 is being dropped right now: #90062

@richkadel
Copy link
Contributor

richkadel commented Oct 21, 2021

@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 instrument-coverage flag (#90132), I definitely think we need to keep LLVM 11 support for as long as feasible, but I fully agree with adding support for Coverage Mapping Format versions 5 and 6, depending on the build-time version of LLVM.

r? @tmandry (this probably doesn't work while the PR is in Draft mode)

@Swatinem
Copy link
Contributor Author

@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.

@wesleywiser
Copy link
Member

Also, since there is now a proposal to stablize the instrument-coverage flag (#90132), I definitely think we need to keep LLVM 11 support for as long as feasible, but I fully agree with adding support for Coverage Mapping Format versions 5 and 6, depending on the build-time version of LLVM.

+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.

@mati865
Copy link
Contributor

mati865 commented Oct 22, 2021

FYI we might end up bumping minimal LLVM to 12: #90175, that will allow to simplify this PR.

@bors
Copy link
Contributor

bors commented Oct 24, 2021

☔ The latest upstream changes (presumably #90175) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Oct 24, 2021
@mati865
Copy link
Contributor

mati865 commented Oct 29, 2021

@Swatinem LLVM 12 is the minimum now.

@Swatinem Swatinem force-pushed the bump-coverage-version branch from d8544b9 to 52c205a Compare November 1, 2021 11:20
@Swatinem Swatinem marked this pull request as ready for review November 1, 2021 11:22
@Swatinem
Copy link
Contributor Author

Swatinem commented Nov 1, 2021

Updated the PR and rebased on latest master, should be ready for review now.

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
Copy link
Member

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.

@tmandry
Copy link
Member

tmandry commented Nov 1, 2021

@bors r+

@bors
Copy link
Contributor

bors commented Nov 1, 2021

📌 Commit 52c205a34fa958f1a5b74c8016e62c21c4d7a08d has been approved by tmandry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 1, 2021
@bors
Copy link
Contributor

bors commented Nov 2, 2021

⌛ Testing commit 52c205a34fa958f1a5b74c8016e62c21c4d7a08d with merge 6fe98430601dc3b277da8938870e10b14f132e3f...

@bors
Copy link
Contributor

bors commented Nov 2, 2021

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 2, 2021
@rust-log-analyzer

This comment has been minimized.

@Swatinem Swatinem force-pushed the bump-coverage-version branch from 52c205a to 99b7e9c Compare November 2, 2021 19:53
@Swatinem
Copy link
Contributor Author

Swatinem commented Nov 2, 2021

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.
From the logs, it looks like the functions (counters) inlined into the main crate are being discarded.

@tmandry
Copy link
Member

tmandry commented Nov 10, 2021

@Swatinem are you still available to investigate the CI failure?

@tmandry tmandry added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 10, 2021
@Swatinem
Copy link
Contributor Author

Haven’t had time yet to investigate, pretty much saturated with other things right now.

@apiraino apiraino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Nov 11, 2021
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.
@richkadel
Copy link
Contributor

Haven’t had time yet to investigate, pretty much saturated with other things right now.

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?

richkadel added a commit to richkadel/rust that referenced this pull request Nov 30, 2021
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=.`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 30, 2021
… 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=.`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 1, 2021
… 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=.`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 1, 2021
… 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=.`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 1, 2021
… 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=.`
@Swatinem
Copy link
Contributor Author

Swatinem commented Dec 1, 2021

Closing in favor of #91207 which subsumes this commit

@Swatinem Swatinem closed this Dec 1, 2021
@Swatinem Swatinem deleted the bump-coverage-version branch December 2, 2021 22:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants