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

[Vedant Kumar via cfe-dev]

> On Sep 26, 2016, at 4:11 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> 
> 
>> 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?

Yes.


>>   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!

Right, this is the main motivation.

thanks,
vedant