Have a way to mark lines as "unreachable by unit tests"

It would be great to have a way to tell the test coverage code "this line won't be reached by tests, so don't worry about it." This would let us have a prayer of reaching 100%.

changed milestone to %Tor: 0.2.9.x-final

added 028-triaged TorCoreTeam201604 actualpoints::small component::core tor/tor milestone::Tor: 0.2.9.x-final owner::nickm points::small priority::high resolution::implemented reviewer::isis severity::normal sponsor::S-can status::closed testing tor-tests-coverage tor-tests-unit type::enhancement labels

Trac:
Owner: N/A to nickm
Status: new to accepted
Milestone: N/A to Tor: 0.2.7.x-final

Trac:
Milestone: Tor: 0.2.7.x-final to Tor: 0.2.8.x-final

Hi,

We can use the lcov exclusion markers like: LCOV_EXCL_LINE, LCOV_EXCL_START, LCOV_EXCL_STOP, LCOV_EXCL_BR_LINE, LCOV_EXCL_BR_START and, LCOV_EXCL_BR_STOP.

The usage will be something like this: /* LCOV_EXCL_START / if (!options->Tor2webMode) { log_err(LD_CONFIG, "This copy of Tor was compiled to run in " "'tor2web mode'. It can only be run with the Tor2webMode torrc " "option enabled."); return -1; } / LCOV_EXCL_STOP */

What do you think if we use macros to have this markers only if the coverage is enable?

Something like: switch(some_value){ case 1: // something break; case 0: // something else break; case -1: TOR_COV_UNREACHABLE_BEGIN //unreachable code TOR_COV_UNREACHABLE_ENF }

Trac:
Username: tdruiva

I don't see the point in using macros here; they don't seem any cleaner than LCOV stuff, right?

(I wonder if any other coverage tools have macros like this that they would expect us to use, and whether we're about to be littered with them...)

The only reason was to abstract from the tool we are using - since Tor source code names the existing macros as COVERAGE_ENABLED (and TOR_COVERAGE) rather than LCOV_ENABLED.

Trac:
Username: rjunior

I don't see the point in using macros here; they don't seem any cleaner than LCOV stuff, right?

Yeah, you're right.

Other point about these lcov exclude markers, we can use in a macro style instead of comment, like

#define LCOV_EXCL_START #define LCOV_EXCL_STOP

LCOV_EXCL_START code . . . LCOV_EXCL_STOP

(I wonder if any other coverage tools have macros like this that they would expect us to use, and whether we're about to be littered with them...)

I'll keep looking

Trac:
Username: tdruiva

Trac:
Keywords: N/A deleted, 028-triaged added

Bulk-replace SponsorS keyword with SponsorS sponsor field in Tor component.

Trac:
Sponsor: N/A to SponsorS
Keywords: SponsorS deleted, N/A added

Trac:
Points: N/A to small
Priority: normal to major

Trac:
Priority: High to Medium

These tickets, though owned by me, are not deliverables I can realistically deliver by the 0.2.8 freeze window.

Trac:
Milestone: Tor: 0.2.8.x-final to Tor: 0.2.9.x-final

Trac:
Sponsor: SponsorS to SponsorS-can

Trac:
Priority: Medium to High

These are infrastructure that will help out other projects, and should go in early. Marking them for April.

Trac:
Keywords: N/A deleted, TorCoreTeam201604 added

I think that the approach from comment:6 above is the best we're going to be able to do. We'll need to teach our own coverage-parsers about them, though.

Trac:
Severity: N/A to Normal
Reviewer: N/A to N/A

Actually, comments are more readable here.

Added an lcov_excl branch to handle the tooling, and to mark some lines in crypto.c

Trac:
Actualpoints: N/A to small
Status: accepted to needs_review

Note: my approach to when we should use these LCOV_EXCL lines differs from the approach taken in tortls.c and config.c so far. I believe that we should only mark a line as excluded when it is truly unreachable. The annotations in tortls.c think that "maybe unreachable" can be a good enough reason.

Trac:
Keywords: N/A deleted, tor-tests-coverage, tor-tests-unit added