Skip to content

[red-knot] Move standalone expr inference to for non-name target#14788

Merged
dhruvmanila merged 1 commit intomainfrom
dhruv/double-extend
Dec 5, 2024
Merged

[red-knot] Move standalone expr inference to for non-name target#14788
dhruvmanila merged 1 commit intomainfrom
dhruv/double-extend

Conversation

@dhruvmanila
Copy link
Member

Summary

Ref: #14754 (comment)

Test Plan

Remove the TODO comment and update the mdtest.

@dhruvmanila dhruvmanila added the ty Multi-file analysis & type inference label Dec 5, 2024
if let ast::Expr::Name(name) = &**target {
self.infer_definition(name);
} else {
self.infer_standalone_expression(iter);
Copy link
Member

Choose a reason for hiding this comment

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

Why is it okay to only infer the iterator when the target isn't a name? Is it because it is otherwise handled in infer_for_statement_definition or is it something else?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, that's correct. It's handled while inferring the definition types. This pattern is also followed in other definitions like assignment, with items, etc.

Copy link
Member Author

Choose a reason for hiding this comment

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

The main reason for this requirement is the self.extend call which duplicated the diagnostics.

@github-actions
Copy link
Contributor

github-actions bot commented Dec 5, 2024

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

@dhruvmanila dhruvmanila merged commit e9941cd into main Dec 5, 2024
@dhruvmanila dhruvmanila deleted the dhruv/double-extend branch December 5, 2024 12:36
Comment on lines 29 to 31
# error: [invalid-syntax]
# error: [invalid-syntax]
# error: [invalid-syntax]
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are there still three invalid-syntax errors? Can we add messages clarifying what the three errors are? I would expect two (one for while used as identifier, the other for pass used as identifier.)

Copy link
Member Author

Choose a reason for hiding this comment

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

In brief, our parser cannot recover from certain syntax errors completely. For example, if there's a keyword (like for) in the middle of another statement (like function definition), then it's more likely that the rest of the tokens are going to be part of the for statement and not the function definition. But, it's not necessary that the remaining tokens are valid in the context of a for statement. This is what's happening here. There's a function definition before this part of the code that the parser doesn't recover well from:

def True(for):
    pass

for while in pass:
    pass

Try commenting out the function definition and you'll get the expected number of errors. I could add this as a general comment to this file.

Playground: https://play.ruff.rs/a36e1a68-abd9-404d-bb79-146855c6d521

dhruvmanila added a commit that referenced this pull request Dec 6, 2024
Ref: #14788 (comment)

This PR:
* Separates code snippets as individual tests for the invalid syntax
cases
* Adds a general comment explaining why the parser could emit more
syntax errors than expected
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ty Multi-file analysis & type inference

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants