-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Various fixes to the fine-grained incremental mode #4438
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
Conversation
Bundling these in a single commit since a single test case reproduces both of these issues and initially it wasn't clear if they are a single issue. 1. Fix AST merge of ClassDefs. 2. If there is a previous error in a class body, refresh module top level instead of the whole class. 3. Generally fix the previous target handling in case of nested definitions (full test coverage missing).
Not sure if this will make a difference anywhere, but this seems like the right thing to do.
TODO: Add test case
I didn't add tests since it's unclear if these actually caused any visible issues.
Not sure if these changes fix user-visible issues, but this at least makes things cleaner.
Not sure if this fixes an user-visible issue, but at least this makes things more consistent.
@@ -129,10 +129,20 @@ class Errors: | |||
# Set to True to show column numbers in error messages. | |||
show_column_numbers = False # type: bool | |||
|
|||
# Stack of active fine-grained incremental checking targets within | |||
# a module. The first item is always the current module id. | |||
# State for keeping track of the current fine-grained incremental mode target. |
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.
Is Errors
the best place to be tracking what target is currently being processed?
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.
Not really. Errors
is tracking this primarily for convenience -- it's the only place that currently has enough context and is available pretty much everywhere. A better approach might be to have a separate context class which would track the current scope and target, and Errors
would get access to this context (but it would only need read-only access). Since this PR doesn't change the responsibilities of Errors
significantly (the wart was already there before), I'd prefer to refactor this in a separate PR.
These fix various issues seen when testing with real-world code.