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

coverage: Count await when the Future is immediately ready #130013

Merged
merged 2 commits into from
Sep 6, 2024

Conversation

jonathan-conder
Copy link
Contributor

Currently await is only counted towards coverage if the containing
function is suspended and resumed at least once. This is because it
expands to code which contains a branch on the discriminant of Poll.

By treating it like a branching macro (e.g. assert!), these
implementation details will be hidden from the coverage results.

I added a test to ensure the fix works in simple cases, but the heuristic of picking only the first await-related covspan might be unreliable. I plan on testing more thoroughly with a real codebase over the next couple of weeks.

closes #98712

@rustbot
Copy link
Collaborator

rustbot commented Sep 6, 2024

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @saethlin (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@rustbot
Copy link
Collaborator

rustbot commented Sep 6, 2024

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred in coverage tests.

cc @Zalathar

Some changes occurred in coverage instrumentation.

cc @Zalathar

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 6, 2024
@saethlin
Copy link
Member

saethlin commented Sep 6, 2024

Hm. r? Zalathar

@rustbot rustbot assigned Zalathar and unassigned saethlin Sep 6, 2024
tests/coverage/async.rs Outdated Show resolved Hide resolved
tests/coverage/async.rs Outdated Show resolved Hide resolved
@Zalathar
Copy link
Contributor

Zalathar commented Sep 6, 2024

I added a test to ensure the fix works in simple cases, but the heuristic of picking only the first await-related covspan might be unreliable. I plan on testing more thoroughly with a real codebase over the next couple of weeks.

The code for extracting coverage spans from MIR is already a big pile of unreliable heuristics, so I can't complain too much here. 😅

Currently `await` is only counted towards coverage if the containing
function is suspended and resumed at least once. A future commit will
fix this and update the test to reflect the new behavior.
Currently `await` is only counted towards coverage if the containing
function is suspended and resumed at least once. This is because it
expands to code which contains a branch on the discriminant of `Poll`.

By treating it like a branching macro (e.g. `assert!`), these
implementation details will be hidden from the coverage results.
@jonathan-conder
Copy link
Contributor Author

Ok I think I've addressed everything. If it turns out separate seen_* variables are needed, we can go back to dbe6851.

@Zalathar
Copy link
Contributor

Zalathar commented Sep 6, 2024

Looks good. I have a few more tiny suggestions for the test file headers, but I'm happy to approve this as-is.

(Also, thanks for having a nice commit history and a separate PR for the status-quo test; it really makes my life easier!)

@bors r+

@bors
Copy link
Contributor

bors commented Sep 6, 2024

📌 Commit 25d1830 has been approved by Zalathar

It is now in the queue for this repository.

@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-review Status: Awaiting review from the assignee but also interested parties. labels Sep 6, 2024
@Zalathar
Copy link
Contributor

Zalathar commented Sep 6, 2024

This is now in rollup, so better not to modify it any further. The remaining test tweaks can be done in #130017, or some other PR.

@jonathan-conder
Copy link
Contributor Author

Ok. I already rebased those changes so I pushed them to a different branch, here is the diff if you want to add it to your PR: https://github.com/jonathan-conder/rust/compare/await_coverage..await_coverage_tweaks

Thanks that was a really quick turnaround!

bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 6, 2024
…iaskrgr

Rollup of 6 pull requests

Successful merges:

 - rust-lang#129021 (Check WF of source type's signature on fn pointer cast)
 - rust-lang#129781 (Make `./x.py <cmd> compiler/<crate>` aware of the crate's features)
 - rust-lang#129963 (Inaccurate `{Path,OsStr}::to_string_lossy()` documentation)
 - rust-lang#129969 (Make `Ty::boxed_ty` return an `Option`)
 - rust-lang#129995 (Remove wasm32-wasip2's tier 2 status from release notes)
 - rust-lang#130013 (coverage: Count await when the Future is immediately ready )

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 11d5614 into rust-lang:master Sep 6, 2024
6 checks passed
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Sep 6, 2024
Rollup merge of rust-lang#130013 - jonathan-conder:await_coverage, r=Zalathar

coverage: Count await when the Future is immediately ready

Currently `await` is only counted towards coverage if the containing
function is suspended and resumed at least once. This is because it
expands to code which contains a branch on the discriminant of `Poll`.

By treating it like a branching macro (e.g. `assert!`), these
implementation details will be hidden from the coverage results.

I added a test to ensure the fix works in simple cases, but the heuristic of picking only the first await-related covspan might be unreliable. I plan on testing more thoroughly with a real codebase over the next couple of weeks.

closes rust-lang#98712
@rustbot rustbot added this to the 1.83.0 milestone Sep 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.

Code coverage misses .await lines
5 participants