[cfe-dev] RFC: Attribute to suppress coverage mapping for functions

[Mehdi Amini via cfe-dev]

> On Sep 26, 2016, at 3:43 PM, Vedant Kumar via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> Hi,
> 
> I'd like to add a new attribute which can be used to suppress code coverage
> reporting on the function level. This is meant to work with clang's
> frontend-based coverage implementation [1]. Here are some potential users of
> the new attribute:
> 
>  * llvm_unreachable_internal.

Shouldn’t LLVM optimize out the instrumentation for it anyway?

> 
>  * The various dump() functions for llvm Values, AST nodes, etc.
> 
>  * Methods in a base class which just call llvm_unreachable.

Same.


> 
> These functions are usually not covered. It's not practical to write "death
> tests" for all of them, and it's also unhelpful to report missing coverage for
> them.
> 
> I'd like to be able to write this in C:
> 
>  void foo() __attribute__((nocoverage)) { llvm_unreachable("boom!"); }
> 
> And this in C++11:
> 
>  void foo() [[clang::nocoverage]] { llvm_unreachable("boom!"); }
> 
> Here are some alternatives and why I think they're not as good:
> 
>  * Define a preprocessor macro when -fcoverage-mapping is enabled.
> 
>    Conditionally compiling code based on whether code coverage is enabled
>    sounds scary. We shouldn't make it easy (or possible?) to change the
>    meaning of a program by enabling coverage.
> 
>  * Pass a function blacklist to llvm-cov.
> 
>    The blacklist would have to live separately from the source code, and may
>    get out of sync. We also would go through the trouble of emitting coverage
>    mappings for functions even though they aren't needed.
> 
>  * Add a pair of pragmas to arbitrarily stop/resume coverage mapping.
> 
>    We'd need some extra diagnostics to catch abuse of the pragmas. It also
>    requires more typing in the common case (disabling coverage at the function
>    level).
> 
>  * Look at the function CFG. If all paths through the function can be shown to
>    reach __builtin_unreachable(), don't create coverage mappings for the
>    function.

Oh I see: even if LLVM optimizes out the counters, you still have ranges/location that will be marked as uncovered in the report, right?


> 
>    I'm worried this might be complicated and inflexible. It wouldn't let us
>    mark dump() functions as uncovered.
> 
> Wdyt?


I agree it is useful to be able to exclude part of a file to make sure the percentage of coverage is more accurate!

Thanks!

— 
Mehdi