linux-test-project / lcov

LCOV
GNU General Public License v2.0
867 stars 235 forks source link

LCOV from master ignores LCOV_EXCL_LINE comments #201

Closed bindreams closed 1 year ago

bindreams commented 1 year ago

LCOV as downloaded from github respects LCOV_EXCL_START/STOP but ignores LCOV_EXCL_LINE.

Here's a reproducible minimal example, in the form of a dockerfile. System configuration:

FROM ubuntu:22.04

RUN apt-get update && apt-get -y dist-upgrade
RUN apt-get install -y gcc git cpanminus make

RUN cpanm install Capture::Tiny DateTime DateTime::Format::W3CDTF Devel::Cover Digest::MD5 File::Spec Cpanel::JSON::XS Memory::Process Time::HiRes
RUN git clone https://github.com/linux-test-project/lcov
RUN cd lcov && make install

Minimal source file:

int main(int argc) {
    if (argc > 10) {
        return 1;  // LCOV_EXCL_LINE
    }

    return 0;
}

I guess when the README said "Use Git for the most recent (but possibly unstable) version" it really did mean that :)

henry2cox commented 1 year ago

Thanks for finding the issue. This appears to be a feature that was implemented for gcc versions less-than-9 - and was never forward-ported, so it doesn't work with newer versions; seems to have been missed when 'gcov -i' (internal format) support was implemented.

The man pages mention both LCOV_EXCL_LINE, LCOV_EXCL_BR_LINE, and LCOV_EXCL_EXCEPTION_BR_LINE - which will need a bit of extra thought and a lot of extra testing. Unfortunately, I will not likely have time to work on this in the near future.

In the meantime - please take a look at the "--omit-lines regexp" feature which will probably do what you want.

Henry

henry2cox commented 1 year ago

This should be fixed in b7f5ed6a42fb9. Please give it a shot and see if it meets your expectations. Please close the issue if it seems addressed - or elaborate on what is missing. Thanks Henry

bindreams commented 1 year ago

We tried this fix on our codebase today and everything seems to be working OK. I really appreciate fixing this so quickly. The work you did in #169 took our coverage pipeline from a headache to a fairly robust tool. And now with this issue closed it's even better.

Thanks for all the effort and can't wait for 2.0. Cheers!