-
-
Notifications
You must be signed in to change notification settings - Fork 435
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] Make missing arc fragments useful to more report generators #1850
Comments
I need to understand more about what you are requesting. I've been de-emphasizing arcs to focus more on true branches. I haven't checked the code, but I thought exit arcs from generator expressions were already removed. |
You know what, this should have been two separate issues. I've split the exit-arcs-from-generator-expressions item to #1852 and I hope I've explained it better there. Let's focus this issue on the first two items. The code at stake for the first two items is like this def fn(pred):
if pred:
print("yes")
fn(True)
fn(False) The LCOV reporter (using the code in #1851) currently generates these BRDA: records for this code:
I want to make "to exit" be "return from 'fn'" instead, the way the HTML reporter would do it. But the problem is that the HTML reporter gets the text "return from 'fn'" from So I am suggesting there should be an API more like the internal |
I've added an |
Doesn’t quite work yet, see discussion in nedbat#1850.
Thanks! I rebased https://github.com/MillionConcepts/coveragepy-fixes/tree/lcov-report-improvements-2 on top of https://github.com/nedbat/coveragepy/tree/nedbat/arc-description-for-1850 and adjusted the code in lcovreport.py to use arc_description. It definitely makes things simpler in the reporter to have this API available. However, it doesn't seem to work for exit arcs. I'm getting "jump to line -1" instead of "return from function 'foo'" consistently. It's supposed to be called via the FileReporter for the source file, right? That wasn't 100% clear to me. The current batch of test failures for #1851 are because of this (and also #1852). |
I've made a pull request into your branch that fixes things. |
Have now gotten around to checking your PR; it looks good on my end, let's see how it does in CI... |
* refactor: don't need this aux variable anymore * feature: add arc_description method for #1850 * [lcov] Refactor LcovReporter.lcov_file Split the bulk of the code in LcovReporter.lcov_file out into two free helper functions, lcov_lines and lcov_arcs. This is easier to read and will make it easier to do future planned changes in a type-safe manner. No functional changes in this commit. * [lcov] Improve reporting of branch destinations. The branch field of a BRDA: record can be an arbitrary textual label. Therefore, instead of emitting meaningless numbers, emit the string “to line <N>” for ordinary branches (where <N> is the arc destination line, and “to exit” for branches that exit the function. When there is more than one exit arc from a single line, provide the negated arc destination as a disambiguator. Thanks to Henry Cox (@henry2cox), one of the LCOV maintainers, for clarifying the semantics of BRDA: records for us. * Implement function coverage reporting in lcov reports. Quite straightforward: a function has been executed if any of its region’s lines have been executed. * [lcov] Ignore vacuous function regions. Should fix the test failures with pypy pretending to be python 3.8. * Adjust test expectations for lcov reports generated under PyPy 3.8. There is a bug somewhere, in which if we collect data in --branch mode under PyPy 3.8, regions for top-level functions come out of the analysis engine with empty lines arrays. The previous commit prevented this from crashing the lcov reporter; this commit adjusts the tests of the lcov reporter so that we expect the function records affected by the bug to be missing. I don’t think it’s worth trying to pin down the cause of the bug, since Python 3.8 is approaching end-of-life for both CPython and PyPy. * Split up test_multiple_exit_branches into 3 tests exercising #1852. * add a fourth case to the tests for #1852 * Revise lcovreport.lcov_arcs using the new arc_description API. Doesn’t quite work yet, see discussion in #1850. * fix: forgot to add arc_descriptions to Python filereporter * refactor: make arc possibilities and arcs executed available * fix: executed_branch_arcs should limit itself to parsed possible arcs * Use tests.helpers.xfail_pypy38 for lcov tests that fail with pypy 3.8. This replaces the custom fn_coverage_missing_in_pypy_38 logic that was used in earlier commits. * tests: split xfail_pypy38 decorator into _older_ and _all_ variants The lcov output tests that are affected by bugs in PyPy 3.8, fail with the current version of PyPy 3.8 (7.3.11), unlike the other tests annotated with @xfail_pypy38. Split this decorator into two variants, xfail_older_pypy38 (used for all the tests that were labeled xfail_py38 prior to this patchset) and xfail_all_pypy38 (used for the lcov output tests). --------- Co-authored-by: Ned Batchelder <[email protected]>
Fixed in commit 6118798. |
This is now released as part of coverage 7.6.2. |
This is following on from the discussion near the end of #1846.
parser.py
has a sophisticated algorithm for characterizing branch arc destinations - ordinary if statement, exiting the function, exiting awith
clause, etc. - but the way it's presently implemented, it is only useful to the HTML report generator. To make it useful to more reporters, I'd like to ask for the following:FileReporter
API, analogous to the existingmissing_arc_description
function, that tersely describes the destination of an arc without any leading text about whether it was or wasn't executed. For ordinaryif
destinations, it'd be most useful to get just "line {lineno}". For function returns, "return from {self.name!r}". And so on.And finally, an exposed API that tells you whether an arc should be ignored, whether or not it was ever taken or not taken. This is for things like(Split to [internal] Generator-expression exit arcs aren't always filtered out of executed_branch_arcs #1852.)if any(pred(x) for x in xs)
, where the uninteresting exit arc from the generator expression gets filtered out of the HTML report by (it seems) always getting executed, but a reporter like LCOV that needs to talk about all the arcs has no good way to tell.The text was updated successfully, but these errors were encountered: