<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 26 September 2016 at 15:43, Vedant Kumar via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
I'd like to add a new attribute which can be used to suppress code coverage<br>
reporting on the function level. This is meant to work with clang's<br>
frontend-based coverage implementation [1]. Here are some potential users of<br>
the new attribute:<br>
<br>
  * llvm_unreachable_internal.<br>
<br>
  * The various dump() functions for llvm Values, AST nodes, etc.<br>
<br>
  * Methods in a base class which just call llvm_unreachable.<br>
<br>
These functions are usually not covered. It's not practical to write "death<br>
tests" for all of them, and it's also unhelpful to report missing coverage for<br>
them.<br>
<br>
I'd like to be able to write this in C:<br>
<br>
  void foo() __attribute__((nocoverage)) { llvm_unreachable("boom!"); }<br>
<br>
And this in C++11:<br>
<br>
  void foo() [[clang::nocoverage]] { llvm_unreachable("boom!"); }<br>
<br>
Here are some alternatives and why I think they're not as good:<br>
<br>
  * Define a preprocessor macro when -fcoverage-mapping is enabled.<br>
<br>
    Conditionally compiling code based on whether code coverage is enabled<br>
    sounds scary. We shouldn't make it easy (or possible?) to change the<br>
    meaning of a program by enabling coverage.<br>
<br>
  * Pass a function blacklist to llvm-cov.<br>
<br>
    The blacklist would have to live separately from the source code, and may<br>
    get out of sync. We also would go through the trouble of emitting coverage<br>
    mappings for functions even though they aren't needed.<br>
<br>
  * Add a pair of pragmas to arbitrarily stop/resume coverage mapping.<br>
<br>
    We'd need some extra diagnostics to catch abuse of the pragmas. It also<br>
    requires more typing in the common case (disabling coverage at the function<br>
    level).<br>
<br>
  * Look at the function CFG. If all paths through the function can be shown to<br>
    reach __builtin_unreachable(), don't create coverage mappings for the<br>
    function.<br>
<br>
    I'm worried this might be complicated and inflexible. It wouldn't let us<br>
    mark dump() functions as uncovered.<br>
<br>
Wdyt?<br>
<br></blockquote><div><br></div><div><br></div><div><div>This definitely sounds like a good idea. I imagine that it will be fairly easy to disable coverage</div><div>for regions which contains just one statement that references a declaration with</div><div>a “nocoverage” attribute. Do you think it will be difficult to handle cases where</div><div>regions have normal statements that are covered mixed with statements which reference</div><div>declarations with a “nocoverage” attribute? Moreover, how will you handle the case of a </div><div>sub-expression referencing a “nocoverage” declaration?</div><div><br></div><div>By the way, do you think that we should have something similar for macros? We obviously</div><div>wouldn’t be able to use the attribute, but it seems like it would be useful to suppress coverage</div><div>for certain macros.</div><div><br></div><div>Alex</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
vedant<br>
<br>
[1] <a href="http://clang.llvm.org/docs/SourceBasedCodeCoverage.html" rel="noreferrer" target="_blank">http://clang.llvm.org/docs/<wbr>SourceBasedCodeCoverage.html</a><br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div></div>