Skip to content

Fix tracing::instrument async block coverage#158276

Open
xd009642 wants to merge 1 commit into
rust-lang:mainfrom
xd009642:async_instr_coverage_fix
Open

Fix tracing::instrument async block coverage#158276
xd009642 wants to merge 1 commit into
rust-lang:mainfrom
xd009642:async_instr_coverage_fix

Conversation

@xd009642

@xd009642 xd009642 commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

Fixes #131119 (or tries to...)

Using tracing::instrument code such as:

  #[tracing::instrument]
  pub async fn fetch(id: u64) -> Result<String, Error> {
      let row = db_get(id).await?;
      Ok(row.name)
  }

Often results in functions with no coverage counters.

Using the following MRE:

use tracing::instrument;

pub async fn plain_async_branch(value: u8) -> &'static str {
    if value.is_multiple_of(2) {
        "plain even"
    } else {
        "plain odd"
    }
}

#[tracing::instrument]
pub fn instrumented_sync_branch(value: u8) -> &'static str {
    if value.is_multiple_of(2) {
        "sync even"
    } else {
        "sync odd"
    }
}

#[tracing::instrument]
pub async fn instrumented_async_branch(value: u8) -> &'static str {
    if value.is_multiple_of(2) {
        "async even"
    } else {
        "async odd"
    }
}

mod tests {
    use super::*;

    #[tokio::test]
    async fn plain_async_branch_reports_coverage() {
        assert_eq!(plain_async_branch(2).await, "plain even");
        assert_eq!(plain_async_branch(3).await, "plain odd");
    }

    #[test]
    fn instrumented_sync_branch_reports_coverage() {
        assert_eq!(instrumented_sync_branch(2), "sync even");
        assert_eq!(instrumented_sync_branch(3), "sync odd");
    }

    #[tokio::test]
    async fn instrumented_async_branch_reports_coverage() {
        assert_eq!(instrumented_async_branch(2).await, "async even");
        assert_eq!(instrumented_async_branch(3).await, "async odd");
    }
}

We find that instrumented_async_branch is always uncovered. An investigation lead me to is_eligible_for_coverage in rustc_mir_transform as being the cause of filtering it out.

After that I ended up taking the very scientific approach of searching const in https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html and seeing the note for constness picking is_const_fn || is_const_trait_impl. (I did also try hir_body_const_context but that seemed to not work for me as things that can potentially be const folded show up?).

Now with this change I see that the region isn't marked as ineligible but somewhere further along in processing it gets removed. This last point is why this PR is still in it's draft state as there still seems to be something afoot removed draft state as I need some input or guidance 😅 .

@rustbot rustbot added 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. labels Jun 23, 2026
@xd009642 xd009642 marked this pull request as ready for review June 23, 2026 00:06
@rustbot

rustbot commented Jun 23, 2026

Copy link
Copy Markdown
Collaborator

Some changes occurred in coverage instrumentation.

cc @Zalathar

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 23, 2026
@rustbot

rustbot commented Jun 23, 2026

Copy link
Copy Markdown
Collaborator

r? @nnethercote

rustbot has assigned @nnethercote.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler, mir, mir-opt
  • compiler, mir, mir-opt expanded to 73 candidates
  • Random selection from 21 candidates

@rustbot

This comment has been minimized.

Attempt to tighten up const-eval based eligibility checks to prevent us
from discarding too many regions.

Using tracing::instrument code such as:

```rust
  #[tracing::instrument]
  pub async fn fetch(id: u64) -> Result<String, Error> {
      let row = db_get(id).await?;
      Ok(row.name)
  }
```

Often results in functions with no coverage counters.

Using the following MRE:

```rust
use tracing::instrument;

pub async fn plain_async_branch(value: u8) -> &'static str {
    if value.is_multiple_of(2) {
        "plain even"
    } else {
        "plain odd"
    }
}

pub fn instrumented_sync_branch(value: u8) -> &'static str {
    if value.is_multiple_of(2) {
        "sync even"
    } else {
        "sync odd"
    }
}

pub async fn instrumented_async_branch(value: u8) -> &'static str {
    if value.is_multiple_of(2) {
        "async even"
    } else {
        "async odd"
    }
}

mod tests {
    use super::*;

    #[tokio::test]
    async fn plain_async_branch_reports_coverage() {
        assert_eq!(plain_async_branch(2).await, "plain even");
        assert_eq!(plain_async_branch(3).await, "plain odd");
    }

    #[test]
    fn instrumented_sync_branch_reports_coverage() {
        assert_eq!(instrumented_sync_branch(2), "sync even");
        assert_eq!(instrumented_sync_branch(3), "sync odd");
    }

    #[tokio::test]
    async fn instrumented_async_branch_reports_coverage() {
        assert_eq!(instrumented_async_branch(2).await, "async even");
        assert_eq!(instrumented_async_branch(3).await, "async odd");
    }
}
```

We find that `instrumented_async_branch` is always uncovered. An
investigation lead me to `is_eligible_for_coverage` in
`rustc_mir_transform` as being the cause of filtering it out.

After that I ended up taking the very scientific approach of searching const in
https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html
and seeing the note for constness picking `is_const_fn ||
is_const_trait_impl`. (I did also try `hir_body_const_context` but that
seemed to not work for me as things that can potentially be const folded
show up?).

Now with this change I see that the region isn't marked as ineligible
but somewhere further along in processing it gets removed. This last
point is why this PR is still in it's draft state as there still seems
to be something afoot.
@xd009642 xd009642 force-pushed the async_instr_coverage_fix branch from 6ccf282 to e741c23 Compare June 23, 2026 00:08
@rust-log-analyzer

Copy link
Copy Markdown
Collaborator

A job failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
  PR_CI_JOB: 1
  IMAGE: x86_64-gnu-gcc
##[endgroup]
    Updating crates.io index
error: failed to get `cookie` as a dependency of package `cookie_store v0.21.1`
    ... which satisfies dependency `cookie_store = "^0.21.1"` of package `ureq v3.0.8`
    ... which satisfies dependency `ureq = "^3"` of package `citool v0.1.0 (/home/runner/work/rust/rust/src/ci/citool)`

Caused by:
  failed to load source for dependency `cookie`

Caused by:
  unable to update registry `crates-io`

Caused by:
  download of co/ok/cookie failed

Caused by:
  curl failed

Caused by:

@nnethercote

Copy link
Copy Markdown
Contributor

This is a small and simple change and it seems reasonable. But I will defer to someone who knows a lot more about this code than I do.

r? @Zalathar

@rustbot

rustbot commented Jun 23, 2026

Copy link
Copy Markdown
Collaborator

Zalathar is not on the review rotation at the moment.
They may take a while to respond.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Coverage information is wrong when using tracing

5 participants