[cfe-dev] [llvm-dev] Ignoring coverage for noreturn decls

[Harlan Haskins via cfe-dev]

> On Mar 28, 2016, at 8:31 PM, Vedant Kumar <vsk at apple.com> wrote:
> 
> + cfe-dev
> 
>> On Mar 28, 2016, at 1:23 PM, Harlan Haskins via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> 
>> Hi all,
>> 
>> Recently I’ve noticed in coverage profiles that llvm_unreachable and the like are considered uncovered because there’s no special behavior in instrumentation to ‘ignore’ noreturn paths.
> 
> FWIW, Daniel Dunbar and a few others have brought up the lack of a flexible "suppress coverage" mechanism as a pain-point.
> 
> There are two separate but related solutions:
> 
>  - We should automatically emit zero mappings for code regions dominated by a call to a noreturn function.
> 
>  - We should offer some general way to 'turn off' coverage for arbitrary chunks of code.
> 
> 
>> While I don’t necessarily think it’s ideal to ignore all noreturn decls, I think there’s definitely room for some heuristics around ignoring things like llvm_unreachable (perhaps opt-in?).
> 
> I think it's actually useful to have coverage for noreturn functions. Googletest lets you write death tests for this sort of thing.
> 
> Maybe it makes sense to emit zero regions at the _callsites_ of noreturn functions instead. Wdyt?

Yep, this is actually what I meant. I definitely think you’re right that we need to inspect the CFG surrounding a noreturn path as well, because code that’s guarded by an llvm_unreachable shouldn’t be counted either.

There doesn’t seem to be a warning for statements after noreturn either:

$ cat noreturn.c
#include <stdio.h>

int main() {
    __builtin_unreachable();
    while (1) puts("Hello, world.");
    return 0;
}

$ clang -Wall -Wpedantic noreturn.c -o noreturn
$ ./a.out
'./a.out' terminated by signal SIGBUS (Misaligned address error)


>> I’m investigating emitting a zero region for all noreturn decls whilst codegenning, as a start.
>> 
>> Anyone have any input as to a) if this is a good idea, or b) how best to implement and expose it?
> 
> It might be interesting to try this and see if the coverage reports really are much nicer.
> 
> thanks
> vedant

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160329/aab2ddfd/attachment.html>