-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
errors: speedup for large error counts #12631
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
Changes from 2 commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
d36a8f3
errors: speedup for large error counts
hugues-aff 425b9f1
address comments
hugues-aff 03b02f8
errors: unify and optimize error filtering
hugues-aff bab5a3a
Update mypy/errors.py
JelleZijlstra f40d0eb
Update mypy/errors.py
JelleZijlstra File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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.
There is a similar mechanism being used in the
infer_overload_return_type
method in this file (grep for.clean_copy
). Can we use that here too?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.
Hmm. It seems like
infer_overload_return_type
creates a new emptyMessageBuilder
/Errors
and uses that to check if any new errors where triggered, which could be achieved by using the newErrorWatcher
. However it also looks like any such errors would then be ignored (not actually make it into the originalErrors
), which theErrorWatcher
approach alone cannot do, and if we're creating a new emptyErrors
then there's not much benefit to theErrorWatcher
approach. Am I missing something?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.
Could we use the
infer_overload_return_type
approach here, so we don't have to introduce the newErrorWatcher
concept? Seems like we could do that here by getting a clean copy, then unconditionally doingself.msg.add_errors
like on line 2293 in visit_comparison_expr.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.
hmm, I think the current approach there needs to be rethought.
Consider on line 1757:
which seems obviously pretty related to the way the
MessageBuilder
inTypeChecker
is created:The explicit patching of the
MessageBuilder
instance is incomplete (expr_checker and pattern_checker are not patched), but more importantly it is very fragile (there might be other places that need patching, the places that need patching are likely to change over time in ways that hard hard to keep track off), and rather ugly to boot. I think instead of using this pattern in more places we should replace it with some variant ofErrorWatcher
that can optionally intercept/discard errors in the originalMessageBuilder
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.
That's a good point. I suspect bug #12665, which we found yesterday, is related to the problem you identify.