Fix tracing::instrument async block coverage

[xd009642]

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");
    }
}

That was all wrong, a new approach has been done! It seems it was caused by looking at the wrong place in the macro expansion tree

[rustbot]

Some changes occurred in coverage instrumentation.

cc @Zalathar

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[rustbot]

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

[nnethercote]

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]

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

[xd009642]

Okay @Zalathar using codex to help with debugging I managed to narrow it down better than my own semi-blind println stumbling around! The actual issue is that the instrumented function contains dummy spans and is evaluated but the actual user code is somewhere else in the expansion tree. This solution should hopefully be better

Removed my old incorrect processing and rebased on latest version. No tests currently for it as I'm not sure what the testing requirements are for the coverage stuff

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Zalathar]

(Sorry for this taking so long. The code in question is delicate enough that I don’t want to add more heuristics without properly understanding them, and the interaction of async and proc-macros is a very tricky business.)

[xd009642]

Sure no problem, I could try to make a project using numerous proc macro crates and async and see how this pr impacts coverage accuracy and then compare against sync proc macro projects as well if that'll help