Change:
impl<'a, 'tcx> Instrumentor<'a, 'tcx> { fn new(pass_name: &'a str, tcx: TyCtxt<'tcx>, mir_body: &'a mut mir::Body<'tcx>) -> Self { let source_map = tcx.sess.source_map(); <del> let (some_fn_sig, hir_body) = fn_sig_and_body(tcx, mir_body.source.def_id()); let body_span = hir_body.value.span; </del> <ins> let def_id = mir_body.source.def_id(); let (some_fn_sig, hir_body) = fn_sig_and_body(tcx, def_id); let mut body_span = hir_body.value.span; if tcx.is_closure(def_id) { // If the MIR function is a closure, and if the closure body span // starts from a macro, but it's content is not in that macro, try // to find a non-macro callsite, and instrument the spans there // instead. loop { let expn_data = body_span.ctxt().outer_expn_data(); if expn_data.is_root() { break; } if let ExpnKind::Macro(..) = expn_data.kind { body_span = expn_data.call_site; } else { break; } } } </ins> let source_file = source_map.lookup_source_file(body_span.lo()); let fn_sig_span = match some_fn_sig.filter(|fn_sig| { fn_sig.span.ctxt() == body_span.ctxt()

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.