You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Explore adding coverage spans for all sources that emit some coverable spans, including macros and the source that invokes the macros.
The current implementation of -Zinstrument-coverage requires choosing a span in which to report coverage. Typically this is the function's or closure's body_span, so functions that invoke macros will have coverage but code within the expanded macro will not have coverage. Or, if the macro starts the body span (if the macro emits the left curly brace), the macro will have coverage, and any code in the calling source (if passed as an argument to the macro) will not get coverage.
This latter effect was a problem for closures that don't include enclosing braces, until PR #84897 .
PR #84897 is better, but limited: The PR removed coverage from a macro that included most of the function logic (on_error!() defined in closure_macro.rs and closure_macro_async.rs coverage tests.)
Instead of the change in PR #84897, if we can actually add spans to all sources that emit some part of the actual covered, expanded function body syntax, I think this will give coverage results everywhere they apply (except perhaps for macros that generate code that splits a statement or terminator implementation across multiple source spans).
The text was updated successfully, but these errors were encountered:
Also, note that, prior to #84897, If I defined multiple macros that called println!() (without curly braces on the macro), and then called at least one of these, llvm-cov with --show-instantiations would report coverage for every instance (call site) of the println!() macro. If they are all 0 (zero), I think it won't report them, which is why at least one must be called.
An example is something like the following:
let a = || println!("foo");let _b = || println("bar");a();
So, if we make the proposed change described in this Issue, coverage spans in commonly-used macros could generate a large number of reported counts or 'uninstantiated` coverages, for every instance of a macro call in a different location.
Since this is probably undesired, we may need to include, with the solution, a flag or coverage option to disable coverage of at least macro spans in some subset of code (by crate? or something).
Explore adding coverage spans for all sources that emit some coverable spans, including macros and the source that invokes the macros.
The current implementation of
-Zinstrument-coverage
requires choosing a span in which to report coverage. Typically this is the function's or closure's body_span, so functions that invoke macros will have coverage but code within the expanded macro will not have coverage. Or, if the macro starts the body span (if the macro emits the left curly brace), the macro will have coverage, and any code in the calling source (if passed as an argument to the macro) will not get coverage.This latter effect was a problem for closures that don't include enclosing braces, until PR #84897 .
PR #84897 is better, but limited: The PR removed coverage from a macro that included most of the function logic (
on_error!()
defined inclosure_macro.rs
andclosure_macro_async.rs
coverage tests.)Instead of the change in PR #84897, if we can actually add spans to all sources that emit some part of the actual covered, expanded function body syntax, I think this will give coverage results everywhere they apply (except perhaps for macros that generate code that splits a statement or terminator implementation across multiple source spans).
The text was updated successfully, but these errors were encountered: