Change:
let mut countdown = 10; let _short_unused_closure = | _unused_arg: u8 | countdown += 1; <del> // Macros can sometimes confuse the coverage results. Compare this next assignment, with an // unused closure that invokes the `println!()` macro, with the closure assignment above, that // does not use a macro. The closure above correctly shows `0` executions. let _short_unused_closure = | _unused_arg: u8 | println!("not called"); // The closure assignment above is executed, with a line count of `1`, but the `println!()` // could not have been called, and yet, there is no indication that it wasn't... // ...but adding block braces gives the expected result, showing the block was not executed. </del> <ins> let short_used_covered_closure_macro = | used_arg: u8 | println!("called"); let short_used_not_covered_closure_macro = | used_arg: u8 | println!("not called"); let _short_unused_closure_macro = | _unused_arg: u8 | println!("not called"); </ins> let _short_unused_closure_block = | _unused_arg: u8 | { println!("not called") }; let _shortish_unused_closure = | _unused_arg: u8 | {

Discussion:
I expect something that looks like the result, for a similar (non-macro) closure: But instead we get results like the following: This issue is demonstrated in the coverage results from the test: I have a new PR in progress to show more examples, and those examples expose the fact that the coverage for is actually being to the macro's source itself. Note that there were 5 macro calls with missing coverage in the corresponding test case, and the coverage report shows 5 . So all are taken into account. Nevertheless, this is a function-like macro, and it should behave like a function call, and show the coverage at the calling site.
I suspect the problem is related to how the expansion is handled for the macro body. When defined without braces, it is (likely) "de-sugared" (adding braces perhaps?) in a way that confuses the macro expansion handling in .
+A-code-coverage fyi:
I looked into this (reviewing debug logs) and the issue it not exactly a macro problem, I think. The closure tests I used all call , and that macro is defined as follows: Note the expansion starts with . That creates a closure that looks like it starts: Since the opening brace comes from the macro, the closure MIR body source starts within the macro. Generating the coverage relative to the source that contains the first character of the function body is generally reasonable, and even in this case it might be hard to argue that it's wrong. But it's probably not right either. The issue is, where should coverage be generated? If the macro is more complex, instrumenting the macro is good. If the caller (which could be another macro, by the way) is more complex, instrumenting the caller source is often better. For example, intuitively we want the coverage results of the two macros below to look similar. Putting the coverage results in the source for the macro loses a lot of coverage span detail! I'm not exactly sure what to do. I'm thinking of treating closures (at least closures that start with a macro) as a special case (at least, when coverage is enabled), and find some way of handling the body span as if it included its own block braces.