Skip to content

bpo-43914: Highlight invalid ranges in SyntaxErrors #25525

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

Merged
merged 11 commits into from
Apr 23, 2021

Conversation

pablogsal
Copy link
Member

@pablogsal pablogsal commented Apr 22, 2021

@pablogsal
Copy link
Member Author

pablogsal commented Apr 22, 2021

@lysnikolaou Could you take a look so we can get this before feature freeze? Some notes:

  • Most of the noise is just propagating the end line and the end offset.
  • I will add new tests (existing tests have been adapted) in a different PR, because this is already gigantic.
  • The Pr is separated into logical commits to make the review easier. As you can see most of the commits is just propagating the end position information everywhere.

@pablogsal pablogsal changed the title Highlight invalid ranges in SyntaxErrors bpo-43914: Highlight invalid ranges in SyntaxErrors Apr 22, 2021
@pablogsal pablogsal marked this pull request as ready for review April 22, 2021 18:23
@pablogsal pablogsal requested a review from markshannon as a code owner April 22, 2021 18:23
@lysnikolaou
Copy link
Member

@pablogsal Yup, I'll have a look tomorrow morning.

Copy link
Member

@lysnikolaou lysnikolaou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really really great work! 🚀

I've left a couple of comments/questions.

RAISE_SYNTAX_ERROR_KNOWN_LOCATION(a, "Generator expression must be parenthesized") }
| a=args ',' '*' { RAISE_SYNTAX_ERROR_KNOWN_LOCATION(a, "iterable argument unpacking follows keyword argument unpacking") }
| a=expression b=for_if_clauses ',' [args | expression for_if_clauses] {
RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, asdl_seq_GET(b, b->size-1)->target, "Generator expression must be parenthesized") }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we use _PyPegen_seq_last_item here?

Copy link
Member Author

@pablogsal pablogsal Apr 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, but it won't be shorter because _PyPegen_seq_last_item is generic and does type erasure so we need to recast to get the target

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I can make it more readable with some macros

Copy link
Member Author

@pablogsal pablogsal Apr 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check out commit 6f01d08

@lysnikolaou
Copy link
Member

I also have some recommendations for the new error ranges. For example I'd prefer:

>>> f(a.b=b*3*4, c)
  File "<stdin>", line 1
    f(a.b=b*3*4, c)
      ^^^^^^^^^
SyntaxError: expression cannot contain assignment, perhaps you meant "=="?

over

>>> f(a.b=b*3*4, c)
  File "<stdin>", line 1
    f(a.b=b*3*4, c)
      ^^^^
SyntaxError: expression cannot contain assignment, perhaps you meant "=="?

I guess, it'd be better to merge this and I'll open another PR to discuss these there. Thoughts?

@pablogsal
Copy link
Member Author

I guess, it'd be better to merge this and I'll open another PR to discuss these there. Thoughts?

Yeah, that one is especially tricky because it (not with what you suggest but I have seen it happen) can make the parser advance too much and the error will be reported too far away from the '=' sign.

@lysnikolaou
Copy link
Member

I guess, it'd be better to merge this and I'll open another PR to discuss these there. Thoughts?

Yeah, that one is especially tricky because it (not with what you suggest but I have seen it happen) can make the parser advance too much and the error will be reported too far away from the '=' sign.

Yup, I can see that happening.

Copy link
Member

@lysnikolaou lysnikolaou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's go! 🎉

Copy link
Member

@lysnikolaou lysnikolaou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only a nit.

Co-authored-by: Lysandros Nikolaou <[email protected]>
@pablogsal pablogsal added the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Apr 23, 2021
@bedevere-bot
Copy link

🤖 New build scheduled with the buildbot fleet by @pablogsal for commit 4e8bb50 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

@bedevere-bot bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Apr 23, 2021
@pablogsal pablogsal added the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Apr 23, 2021
@bedevere-bot
Copy link

🤖 New build scheduled with the buildbot fleet by @pablogsal for commit 4e8bb50 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

@bedevere-bot bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Apr 23, 2021
@pablogsal pablogsal merged commit a77aac4 into python:master Apr 23, 2021
@bedevere-bot
Copy link

@pablogsal: Please replace # with GH- in the commit message next time. Thanks!

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

Successfully merging this pull request may close these issues.

4 participants