Coder Social home page Coder Social logo

Comments (8)

latk avatar latk commented on August 24, 2024 2

I don't think this is possible. Not only would lcov have to expand those macros in order to understand whether a line/branch should be excluded, comments are also removed by the preprocessor. So there's no way to put this info into a macro.

The better alternative might be to configure the exclusion markers to also match these macro names. The lcovrc man page suggests something like this should work:

lcov_excl_br_line = LCOV_EXCL_BR_LINE|g_return_if_fail|g_return_val_if_fail

(and so on for all the macro names)

from lcov.

marxin avatar marxin commented on August 24, 2024 1

Maybe this could be added to GCC? Adding @marxin to the discussion: Is the ability to mark code as to be excluded from code coverage measurements something that could be implemented in GCC?

One can use no_instrument_function function attribute for the else branch in a macro. That should skip instrumentation. That's what I can offer.

from lcov.

pwithnall avatar pwithnall commented on August 24, 2024

I’ll give that a go, thanks. The downside of that is that every project which uses those macros from GLib (which is a lot of projects) will have to learn about and copy the same lcovrc configuration when they do code coverage, which seems highly redundant. I don’t think any project would ever reasonably want to have coverage of the branches in those macros — they’re essentially equivalent to assert().

from lcov.

mosra avatar mosra commented on August 24, 2024

What about using the _Pragma() C99 / C++11 preprocessor command for this? For example, lcov could support detectings things like

#pragma LCOV EXCL_START

in addition to comments. Unlike with comments, the preprocessor preserves these in the output (but yes, it would still need to look into the preprocessor output for these, which I'm not sure it is doing already). The macro could then look like this:

#define g_return_if_fail(expr) \
    _Pragma("LCOV EXCL_START") \
    do { if(!(expr)) ... } while(0) \
    _Pragma("LCOV EXCL_STOP")

Of course, this will make GCC complain on -Wall, so with the warning suppressed it becomes a bit hairy:

#define g_return_if_fail(expr) \
    _Pragma("GCC diagnostic push") \ 
    _Pragma("GCC diagnostic ignored \"-Wunknown-pragmas\"") \
    _Pragma("LCOV EXCL_START") \
    do { if(!(expr)) ... } while(0) \
    _Pragma("LCOV EXCL_STOP") \
    _Pragma("GCC diagnostic pop")

Opinions? :)

from lcov.

oberpar avatar oberpar commented on August 24, 2024

LCOV does not look at preprocessed code output, only at the original source code files associated with each coverage data file (.gcda). I don't see a feasible way to implement this feature in LCOV.

Maybe this could be added to GCC? Adding @marxin to the discussion: Is the ability to mark code as to be excluded from code coverage measurements something that could be implemented in GCC?

from lcov.

feliwir avatar feliwir commented on August 24, 2024

Any progress on this issue?

from lcov.

B-HWD avatar B-HWD commented on August 24, 2024

Still no progress?

from lcov.

henry2cox avatar henry2cox commented on August 24, 2024

Just noticing/revisiting this issue.

I believe that @latk 's comment above is the best approach given that neither gcc nor llvm are likely to make the required enhancements to support the feature, and that lcov/geninfo/genhtml are rather simple tools and are not likely to become full-fledged compilers.

@pwithnall is also correct: all projects that want to use this feature will have to learn about it :-(
If this is a serious problem - then we could either add the required exclusion regexps to the lcovrc shipped with lcov releases (either in a commented out section or as is) - or a (brief) discussion of this issue could be added to the man page.

Now that we allow multiple RC files (see the --config-file option in the man page): we could add all of these typical/recommended exclusions to another RC file that we also include with the release - and add a corresponding discussion to the man pages.

What do people think?

Henry

from lcov.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.