Coverage instruments closure bodies in macros (not the macro body)

[richkadel]

Fixes: #84884

This solution might be considered a compromise, but I think it is the
better choice.

The results in the closure.rs test correctly resolve all test cases
broken as described in #84884.

One test pattern (in both closure_macro.rs and
closure_macro_async.rs) was also affected, and removes coverage
statistics for the lines inside the closure, because the closure
includes a macro. (The coverage remains at the callsite of the macro, so
we lose some detail, but there isn't a perfect choice with macros.

Often macro implementations are split across the macro and the callsite,
and there doesn't appear to be a single "right choice" for which body
should be covered. For the current implementation, we can't do both.

The callsite is most likely to be the preferred site for coverage.

r? @tmandry
cc: @wesleywiser

[richkadel]

@tmandry - This is also just 1 commit, but shows three because it depends on #84797 (due to the test relocation to run-make.

[richkadel]

I do have a new idea to explore, but still believe this PR is the right intermediate solution.

So, just FYI, in a future PR I think this may work:

When collecting spans in spans.rs, I currently only add spans that are within the body_span. If a Statement/Terminator span is an expansion span, I use original_sp() to try to find a pre-expansion span (for example, a span within the macro call itself) if that span is in the body span. (If not, it just returns the body span, which generally just makes the span irrelevant). And this works well for coverage within the function body, wherever the body starts from (which can be in a macro).

I think I can improve on this by returning ALL spans for every statement/terminator, that is, return the given span, it's parent span if any, and all other ancestor spans.

Then when sorting the initial_spans, I will include the ctxt in the sort criteria (to keep them separate), and I would have to adjust span comparisons to take ctxt into account (I should only compare span.lo() or span.hi() when two spans are in the same ctxt).

With that change, I should be able to still add all resolved (selected and/or merged) spans to the same refined_spans collection and add the Coverage statements as before.

Some debugging features (e.g., spanview) may assume all spans are in the same file and contiguous function block, so there will probably be some cleanup needed to support this.

I think the coverage map generation code might also assume all spans for a single function are associated with a single file, and if so, I'll need to make some adjustments to support multiple files for a given function.

But generally this seems doable, and seems like we would get even more coverage of macros, plus coverage of macro callers if the body starts in a macro. (It shouldn't matter anymore either way.)

[tmandry]

@bors r+

[bors]

📌 Commit cb70221 has been approved by tmandry

[tmandry]

@bors rollup