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

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]

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

[rust-log-analyzer]

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]

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.

[Zalathar]

Going from “selectively allow” to ”selectively reject” feels like the wrong approach here.

It's hard to be confident that this change would be correct today, and would remain correct in the future.

View changes since the review

[xd009642]

Okay, so my current aim is all fn-likes that aren't in a const eval context. With a focus on giving the current place where coverage is missing. Do you have a suggestion on roughly what I should be using in TyCtx to achieve that? Or if another approach should be taken