Skip to content
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

Avoid coverage.py balking on "stringsource" #4440

Merged
merged 2 commits into from
Nov 7, 2021
Merged

Conversation

segevfiner
Copy link
Contributor

Having a code object with co_filename set to just "stringsource", causes coverage.py to think that "stringsource" is a relative path to an actual file. The convention is to wrap such fake paths with angle brackets, which coverage.py correctly recognizes.

You will recognize this as the error:

No source for code: '.../stringsource'.
Aborting report output, consider using -i.

When running coverage html for example

Having a code object with `co_filename` set to just "stringsource", causes coverage.py to think that "stringsource" is a relative path to an actual file. The convention is to wrap such fake paths with angle brackets, which coverage.py correctly recognizes.

You will recognize this as the error:
    No source for code: '.../stringsource'.
    Aborting report output, consider using -i.

When running coverage html for example
@segevfiner segevfiner mentioned this pull request Nov 2, 2021
4 tasks
@scoder scoder added this to the 3.0 milestone Nov 2, 2021
@scoder
Copy link
Contributor

scoder commented Nov 2, 2021

Makes sense, probably ok to change it, but calls for at least an integration test with coverage.py. See the tests/run/coverage_*.srctree tests. They are just text files that concatenate a bunch of different files into one to unfold into a directory structure.

Not sure what exactly is missing here. Might be a usage of memory views…? That would suggest adding a separate srctree test for this.

@segevfiner
Copy link
Contributor Author

Makes sense, probably ok to change it, but calls for at least an integration test with coverage.py. See the tests/run/coverage_*.srctree tests. They are just text files that concatenate a bunch of different files into one to unfold into a directory structure.

Not sure what exactly is missing here. Might be a usage of memory views…? That would suggest adding a separate srctree test for this.

The trigger seems to be having a cdef class, not sure where would be the best place to add one in those tests. We also somehow need to make sure that there is no "stringsource" in the output coverage profile to be sure... Any suggestions?

@da-woods
Copy link
Contributor

da-woods commented Nov 2, 2021

The trigger seems to be having a cdef class, not sure where would be the best place to add one in those tests.

It's probably the auto-pickle code that a cdef class generates if all its contents are pickleable. Not sure where the best place to place the test is though (I've never really looked into coverage)

@scoder
Copy link
Contributor

scoder commented Nov 3, 2021 via email

@segevfiner
Copy link
Contributor Author

OK, tried to add a test for this.

P.S. As a workaround I added omit = stringsource to my .coveragerc in my project

@scoder scoder merged commit b96ae4d into cython:master Nov 7, 2021
@scoder
Copy link
Contributor

scoder commented Nov 7, 2021

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants