-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Fix used-before-assignment
TYPE_CHECKING false negatives
#8431
Fix used-before-assignment
TYPE_CHECKING false negatives
#8431
Conversation
used-before-assignment
TYPE_CHECKING false negatives
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #8431 +/- ##
=======================================
Coverage 95.91% 95.91%
=======================================
Files 174 174
Lines 18368 18389 +21
=======================================
+ Hits 17617 17638 +21
Misses 751 751
|
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.
Hey, thanks for jumping on this! Mainly I'm wondering if what happens if we use in_type_checking_block
, which has seen much more development. Is the implementation any simpler?
used-before-assignment
TYPE_CHECKING false negativesused-before-assignment
TYPE_CHECKING false negatives
I'm also sort of wondering if the variables checker shouldn't be using the typing guard at all. We have a concept in the variables checker of names that are guarded under "always false" tests and thus not available at runtime. This seems to raise the warning we want, although I don't know what effect it has on unused-variable: diff --git a/pylint/checkers/variables.py b/pylint/checkers/variables.py
index 734231103..a0016606e 100644
--- a/pylint/checkers/variables.py
+++ b/pylint/checkers/variables.py
@@ -780,10 +780,11 @@ scope_type : {self._atomic.scope_type}
"""
uncertain_nodes = []
for other_node in found_nodes:
- if in_type_checking_block(other_node):
- continue
-
- if not isinstance(other_node, nodes.AssignName):
+ if isinstance(other_node, nodes.AssignName):
+ name = other_node.name
+ elif isinstance(other_node, (nodes.Import, nodes.ImportFrom)):
+ name = node.name
+ else:
continue
closest_if = utils.get_node_first_ancestor_of_type(other_node, nodes.If)
@@ -796,7 +797,7 @@ scope_type : {self._atomic.scope_type}
# Name defined in every if/else branch
if NamesConsumer._exhaustively_define_name_raise_or_return(
- other_node.name, closest_if
+ name, closest_if
):
continue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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 you rebase on the latest main, please ?
I'm on it, made a mistake while trying to rebase and squash to tidy up the log |
This comment has been minimized.
This comment has been minimized.
used-before-assignment
TYPE_CHECKING false negativesused-before-assignment
TYPE_CHECKING false negatives
Let me know if there is anything that needs to be updated according to the latest primer results. |
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.
Neat change ! Sorry for the delay in reviewing, I was conferencing and teaching the youngling.
Didn't look closely at the primer results and no time to do it atm.
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.
Thanks for fixing this difficult false negative! Nice refactors also.
Didn't look closely at the primer results and no time to do it atm.
The last one is a real bug in sentry. The others are already captured in #8167, which we have some time to fix before 3.0.
Co-authored-by: Jacob Walls <jacobtylerwalls@gmail.com>
Type of Changes
Description
This PR addresses false negative cases for
used-before-assignment
, when imports are made withinTYPE_CHECKING
guard clauses.The root cause of these false negatives is the consumption of
Import
,ImportFrom
nodes withinTYPE_CHECKING
clauses. Upon consumption, subsequent usages are not evaluated by the checker.My approach is to not consume these nodes and keep track of usage scopes, so that errors can be emitted in multiple scopes.
Feel free to discuss alternative solutions! π
Closes #8198