Change:
<ins> // compile-flags: --edition=2018 use core::{ future::Future, marker::Send, pin::Pin, }; fn non_async_func() { println!("non_async_func was covered"); let b = true; if b { println!("non_async_func println in block"); } } // FIXME(#83985): The auto-generated closure in an async function is failing to include // the println!() and `let` assignment lines in the coverage code region(s), as it does in the // non-async function above, unless the `println!()` is inside a covered block. async fn async_func() { println!("async_func was covered"); let b = true; if b { println!("async_func println in block"); } } // FIXME(#83985): As above, this async function only has the `println!()` macro call, which is not // showing coverage, so the entire async closure _appears_ uncovered; but this is not exactly true. // It's only certain kinds of lines and/or their context that results in missing coverage. async fn async_func_just_println() { println!("async_func_just_println was covered"); } fn main() { println!("codecovsample::main"); non_async_func(); executor::block_on(async_func()); executor::block_on(async_func_just_println()); } mod executor { use core::{ future::Future, pin::Pin, task::{Context, Poll, RawWaker, RawWakerVTable, Waker}, }; pub fn block_on<F: Future>(mut future: F) -> F::Output { let mut future = unsafe { Pin::new_unchecked(&mut future) }; use std::hint::unreachable_unchecked; static VTABLE: RawWakerVTable = RawWakerVTable::new( |_| unsafe { unreachable_unchecked() }, // clone |_| unsafe { unreachable_unchecked() }, // wake |_| unsafe { unreachable_unchecked() }, // wake_by_ref |_| (), ); let waker = unsafe { Waker::from_raw(RawWaker::new(core::ptr::null(), &VTABLE)) }; let mut context = Context::from_waker(&waker); loop { if let Poll::Ready(val) = future.as_mut().poll(&mut context) { break val; } } } } </ins>

Discussion:
I tried to generate test code coverage with this source file using and the LLVM tools. Source File: I expected to see this happen: Instead, this happened: . cargo-kcov, -Zprofile+grcov, and tarpaulin agree on 76%. In the output below lines , , were not executable but should have been executable+uncovered. Line should be executable+covered. <details<summarycoverage output</summary<p</p</details:
label: +A-code-coverage cc
Thanks for the bug report ! There was a recent bug fix (PR ) that addresses most of the missing coverage in your example (except for the last one). I just tested with and I see the expected coverage now for the first three ranges you reported seeing no coverage. These three are now showing coverage (with 0 executions) as expected: I was surprised to see no coverage for line 169, and I do see the did print, so that does seem to be a bug. So as of today, this issue is still a bug that I will need to look into further:
cc: Note, here is a snippet showing the missing coverage and code relevant to its codepath. I haven't thoroughly investigated this. I should be able to reproduce this in a simplified test (without the asynctrait and executor dependencies) that I can add to our unit tests. I don't have a theory yet. It could either be the closure's MIR is not included in coverage (seems unlikely to me), or is silently dropping coverage because it doesn't like something. (This is what was happening for the other missing coverage reported in this issue, that has since been resolved.) The test (shown at the bottom) calls and awaits the implementation of below: I do see the test output, including the from above, and from the awaited call to , below: The async closure seems to be missing coverage, as shown here. Note the wrapper function is covered and called (showing the coverage of on line 168), but there should also be coverage for the awaited implicit closure (lines 168-170, I believe). Since the program output proves this is called, the coverage should be showing execution. And the test that invokes it is covered:
Thank you. I see improvement in the latest nightly.

I minified the test case to the async issues for anyone looking at this (but it still uses executor and asynctrait.) Since this function is missing coverage too the issue isn't specific to async_trait thought.
So it turns out that the internal (auto-generated) closure actually does get coverage, but for some reason the code region for the macro, by itself, is not or not counted. I've created a draft PR with a new test and current results, demonstrating this issue. Once I figure out how to fix it, I'll submit the PR with the updated results.
Update: fixes the issue.