-
-
Notifications
You must be signed in to change notification settings - Fork 428
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[internal] Generator-expression exit arcs aren't always filtered out of executed_branch_arcs #1852
Comments
Are you sure you are running the code from the tip of master when measuring coverage? There should no longer be a (4, -4) arc in the data, as of commit 2afe04d:
|
Yes, I'm sure. I added three tests to the testsuite specifically for this; all of the test failures on the most recent push for #1851 are because in two out of three cases the equivalent of the (4, -4) arc is visible to the lcov reporter. |
Fine-tuned the tests a little more in commit 402bee8. Given this function def foo(a):
if any(x > 0 for x in a):
print(f"{a!r} has positives") the genexpr exit arc is pruned by the analysis engine if and only if the arc exiting the whole function is never taken. For example, if |
Consider this code snippet:
(Any use of a generator expression in the controlling condition of an
if
should provoke the problem, albeit I have not tried it with a multi-line controlling condition.)If I run this snippet as
coverage run --branch test.py
orcoverage run --branch test.py nonoption
it produces this arc table:If I run it as
coverage run -branch test.py -flag
I get this arc table instead:The problem is with the arc
(4, -4)
, which is (as far as I can tell) the exit arc for the generator expression. The analysis code is supposed to be filtering this arc out as uninteresting, but either it only does this formissing_branch_arcs()
and not forexecuted_branch_arcs()
, or there's a bug in its handling of this construct. When the input is the first of the above two arc tables,executed_branch_arcs()[4]
is{-4, -3, 4}
.The HTML report generator doesn't care about this because it only looks at missing arcs, but the LCOV report generator looks at both missing and executed arcs and trips over the
(4, -4)
edge. With the code in #1851, the difference incoverage lcov
output for the above two arc tables isThe BRDA: lines we should be generating are
but I do not see any way to make that happen from inside lcovreport.py.
The text was updated successfully, but these errors were encountered: