mypy does not check the code after the line with lambda function that calls NoReturn function about mypy

[ravilnicki]

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.

[ravilnicki]

I've found the culprit - 3bf8521.

[ravilnicki]

@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.

[ikonst]

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.

[ravilnicki]

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?

[ikonst]

Yeah, fixing the false unreachable is probably the way to go.

[andersk]

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 NoReturn in 9406886 = v0.500~45.

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

[andersk]

It looks like the problem is that ExpressionChecker.visit_lambda_expr never pushes a new Frame onto self.chk.binder, and unreachability is associated with a Frame so it leaks outside the lambda body.

Indeed, this effect is noted in a comment there, although the chosen solution only works around unreachability from the implicit return statement and not other kinds of unreachability:

mypy/mypy/checkexpr.py

Lines 5227 to 5235 in 43a605f

	# Lambdas can have more than one element in body,
	# when we add "fictional" AssigmentStatement nodes, like in:
	# `lambda (a, b): a`
	for stmt in e.body.body[:-1]:
	stmt.accept(self.chk)
	# Only type check the return expression, not the return statement.
	# This is important as otherwise the following statements would be
	# considered unreachable. There's no useful type context.
	ret_type = self.accept(e.expr(), allow_none_return=True)