tracing: #[instrument] macro interferes with LLVM-based instrument-coverage

[davidbarsky]

Bug Report

Version

coverage-repro on  master is 📦 v0.1.0 via 🦀 v1.62.0-nightly
❯ cargo tree
coverage-repro v0.1.0 (/Users/dbarsky/Developer/coverage-repro)
└── tracing v0.1.34
    ├── cfg-if v1.0.0
    ├── pin-project-lite v0.2.8
    ├── tracing-attributes v0.1.20 (proc-macro)
    │   ├── proc-macro2 v1.0.37
    │   │   └── unicode-xid v0.2.2
    │   ├── quote v1.0.18
    │   │   └── proc-macro2 v1.0.37 (*)
    │   └── syn v1.0.91
    │       ├── proc-macro2 v1.0.37 (*)
    │       ├── quote v1.0.18 (*)
    │       └── unicode-xid v0.2.2
    └── tracing-core v0.1.26
        └── lazy_static v1.4.0

I made a reproduction in davidbarsky/tracing-coverage-reproduction. Note that to reproduce this issue, llvm-tools-preview and grcov are required. To install those tools:

rustup component add llvm-tools-preview
cargo install grcov

Platform

❯ uname -a
Darwin dbarsky-mbp 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar 18 00:46:32 PDT 2022; root:xnu-8020.101.4~15/RELEASE_ARM64_T6000 arm64

❯ rustc --version
rustc 1.62.0-nightly (ec77f2524 2022-04-17)

❯ cargo --version
cargo 1.62.0-nightly (dba5baf43 2022-04-13)

❯ grcov --version
grcov 0.8.9

❯ rustup show
Default host: aarch64-apple-darwin
rustup home:  /Users/dbarsky/.rustup

installed toolchains
--------------------

stable-aarch64-apple-darwin (default)
nightly-2021-11-29-aarch64-apple-darwin
nightly-aarch64-apple-darwin

active toolchain
----------------

nightly-aarch64-apple-darwin (directory override for '/Users/dbarsky/Developer/coverage-repro')
rustc 1.62.0-nightly (ec77f2524 2022-04-17)

Crates

• tracing 0.1.32

Description

The #[instrument] macro appears to mess with the LLVM's code coverage. This might be inherent to macros that rewrite function bodies, as #[instrument] does. Here is the code coverage on a function decorated with #[instrument]:

...and here is a function without #[instrument]:

(This was reported to me by @DirectXMan12.)

[davidbarsky]

I've confirmed that #[async_trait] doesn't have this issue. cargo rustc --profile=check -- -Zunpretty=expanded does show that the #[instrument] macro expands into something a bit more complex than #[async_trait].

[davidbarsky]

This might be caused by rust-lang/rust#110486.

[davidbarsky]

I've confirmed that this is still an issue on rustc 1.77.0-nightly (a2d9d73e6 2024-01-10).