Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
bpo-40612: Fix SyntaxError edge cases in traceback formatting #20072
bpo-40612: Fix SyntaxError edge cases in traceback formatting #20072
Changes from 5 commits
87e78b5
b951b0f
ea1c6f2
72e5b93
6df7662
1c7e6bb
31641ff
f93a54c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just fyi this code right here is the one that I mentioned in we-like-parsers#121 (comment)
Whereby a SyntaxError with an offset relative to the start of the file will end up pointing to the right place. I'm tempted to say we should eventually just remove it since the new parser will always provide line-relative offsets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm... Why would the offset in the SyntaxError object ever end up being file-relative? Do you know of any code that produces such SyntaxErrors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the old parser it was this code:
cpython/Parser/parsetok.c
Lines 425 to 431 in 4a12d12
tok->cur
is the current read index of the tokenizer andtok->buf
is the start of the file. Also see how it copies the entire file up till the error into theSyntaxError.text
field.Try this out with the old parser as a quick example:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, you mean the opposite of file. :-) It occurs when it's not read from a file.
Also it doesn't occur all the time -- perhaps only when there's a continuation line? E.g. here all is good:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, your example does show up weird in the old parser:
The new parser seems to solve the dilemma by suppressing the source text (also the offset is set to zero, meaning unknown):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aah yes, it seems like it's just an issue with line continuations. I thought I had another example but it must have been a misunderstanding because
tok->buf
gets advanced with newlines.So I guess this code here in
pythonrun.c
is just for this one case?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, so I have a serious question here. Is there a regression due to this PR for people using
-X oldparser
? I have tried to research this and cannot find a regression. The C code in pythonrun.c still skips through newlines. The traceback.py code doesn't, but it never did.Here is what I did for research. First Python 3.8:
Then the master branch:
To me that looks like in both versions, the C formatter (invoked by
raise
) does the right thing, while traceback.py messes up the output.