-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
mypy does not check the code after the line with lambda function that calls NoReturn function #17254
Comments
It looks like this bug was introduced in version 1.5.0. I tested previous versions and version 1.4.1 is the last one that works as expected. |
I've found the culprit - 3bf8521. |
@ikonst please take a look file mypy/checker.py line 467- - if (
- self.binder.is_unreachable()
- and self.should_report_unreachable_issues()
- and not self.is_raising_or_empty(d)
- ):
- self.msg.unreachable_statement(d)
- break
- self.accept(d)
+ if self.binder.is_unreachable():
+ if not self.should_report_unreachable_issues():
+ break
+ if not self.is_noop_for_reachability(d):
+ self.msg.unreachable_statement(d)
+ break
+ else:
+ self.accept(d) In the previous version it was possible for self.accept(d) to run even if the self.binder.is_unreachable() was True (eg when self.should_report_unreachable_issues() was False). After your changes when self.binder.is_unreachable() is True there is no possibility to run self.accept(d). In the example I provided (the one with lambda function) the line after lambda is marked as unreachable which I think is also not right. Nevertheless in versions before 1.5.0 this is not an issue and the next lines are checked. |
You can see me discussing in the PR that maybe the right thing to do is not to avoid type checking unreachable code. I just don't think I ever got to make that change since it seemed larger. |
How do you think we should proceed? I think that mypy falsely marks the statement after this lambda expression as an unreachable code. So that is the actual bug. In the older versions it went unnoticed though and after your change it stopped checking the presumably unreachable code. I think it shouldn’t be marked as u reachable in the first place. What do you think @ikonst? |
Yeah, fixing the false unreachable is probably the way to go. |
By moving the code into a function (and adjusting for syntax modernization), I can reproduce the same bug all the way back to the original introduction of from mypy_extensions import NoReturn
def foo():
# type: () -> NoReturn
raise
def main():
# type: () -> None
f = lambda _: foo() # when this line is commented mypy works as expected
bar = "baz" # type: int |
It looks like the problem is that Indeed, this effect is noted in a comment there, although the chosen solution only works around unreachability from the implicit Lines 5227 to 5235 in 43a605f
|
Fixes python#17254. Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Fixes python#17254. Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Fixes #17254 Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Bug Report
mypy does not check the code after the line with lambda function that calls NoReturn function
To Reproduce
Check the code below. I also attached a mypy Playground link.
https://mypy-play.net/?mypy=latest&python=3.12&gist=a924d0f423440c8a1a48348f49edae4e
Expected Behavior
mypy checks the code after line with lambda function that calls NoReturn function, not only the code before that line
Actual Behavior
mypy does not check the code after the line with lambda function that calls NoReturn function
Environment
Edit
I edited the used mypy version because I noticed the same bug in many versions.
The text was updated successfully, but these errors were encountered: