Nothing Special   »   [go: up one dir, main page]

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

multiline f-strings with backslash continuation cause extra lines and misaligned coverage info in HTML report #1836

Closed
the-13th-letter opened this issue Aug 25, 2024 · 7 comments
Labels
bug Something isn't working

Comments

@the-13th-letter
Copy link

Describe the bug

When a line of code ends on a multiline f-string that contains backslash continuation in the first line, the coverage HTML report inserts a synthetic line containing the backslash continuation's backslash at the same position (i.e. a line with a lot of whitespace, and then a backslash), following that line. This also increases the total line count. All following lines with coverage info are then misaligned, because the annotation gets assigned to the original line numbers, not the shifted ones.

To Reproduce

(Running Python 3.12.4 on Linux, in a fresh venv, using coverage 7.6.1 installed via pip install 'coverage === 7.6.1'.)

bug.py

prog_name = 'bug.py'
err_msg = f"""\
{prog_name}: ERROR: This is the first line of the error.
{prog_name}: ERROR: This is the second line of the error.
\
{prog_name}: ERROR: This is the third line of the error.
"""
if (lambda: None)():  # just some non-constant always-false predicate
    'This line intentionally is not covered.'
'This line is covered again.'

Shell commands

$ coverage run --branch python3.12 bug.py && coverage html
Wrote HTML report to htmlcov/index.html

Screenshot of the output:

(screenshot)

Note the synthetic line 3, the misaligned partial/missing coloration on lines 8 and 9 (belonging to the code on lines 9 and 10), and the completely absent coloring of line 11. Note further that line 5 (6 in the screenshot) does not get its own synthetic line. Note finally that the syntax highlighting does not mark lines 2–8 as a string.

Expected behavior

I would expect the HTML rendering of the code bug.py to match the actual code of bug.py.

Additional context

  • I could not reproduce this behavior if a b-string, u-string or r-string is used, but I could reproduce it with fr- and rf-strings.
  • The other report types (JSON, XML, LCOV, text) are fine. In particular, the text-annotated version contains no synthetic lines, and all markers are at the right place.
  • I tried switching to the Python trace function (run --timid) instead of the C trace function, and also tried the 3.12 sysmon core, but that didn't change anything. Which strengthens my belief that the collected data is fine, just the HTML reporter is not.
@the-13th-letter the-13th-letter added the bug Something isn't working label Aug 25, 2024
@nedbat
Copy link
Owner
nedbat commented Aug 25, 2024

@LiuYinCarl can you take a look at this? It sounds like the issue you fixed.

@LiuYinCarl
Copy link
Contributor

@nedbat I just test it with version 7.6.1, but is works fine. Please give me a little more time to find the truth.

image

@the-13th-letter Can you use 7.6.0 to test it again with same file and same environment.

@LiuYinCarl
Copy link
Contributor

@the-13th-letter I just test it with python3.12 and find some thing.

image

image

It seems like it has existed before version 7.6.0 and is only available on python3.12.

@LiuYinCarl
Copy link
Contributor

python3.12 have some change in Lib/token.py, I find a method to solve the buy, I will make a PR later

@the-13th-letter
Copy link
Author

@LiuYinCarl My apologies, I had already tested 7.6.0 and 7.0.0, but forgotten to mention that in the initial report. On the other hand, I had never thought to test it with different Python versions.

python3.12 have some change in Lib/token.py [...]

So it seems. The "what's new?" entry says it has to do with better f-string parsing (PEP 701).

LiuYinCarl added a commit to LiuYinCarl/coveragepy that referenced this issue Sep 4, 2024
@nedbat
Copy link
Owner
nedbat commented Sep 4, 2024

Fixed in commits 515d99c and a77bba7. Thanks!

@nedbat nedbat closed this as completed Sep 4, 2024
@nedbat
Copy link
Owner
nedbat commented Oct 9, 2024

This is now released as part of coverage 7.6.2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants