Skip to content

Do not cache fast container types inside lambdas #20166

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.

Sign up for GitHub

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 1 commit into from
Nov 3, 2025
+22 −2
Merged

Do not cache fast container types inside lambdas #20166

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 8 additions & 2 deletions mypy/checkexpr.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5082,7 +5082,10 @@ def fast_container_type(
self.resolved_type[e] = NoneType()
return None
ct = self.chk.named_generic_type(container_fullname, [vt])
self.resolved_type[e] = ct
if not self.in_lambda_expr:
# We cannot cache results in lambdas - their bodies can be accepted in
# error-suppressing watchers too early
self.resolved_type[e] = ct
Copy link
Collaborator

@A5rocks A5rocks Nov 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't there an expr cache that stores errors too? Is it possible to use that instead?

Copy link
Collaborator Author

@sterliakov sterliakov Nov 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already explicitly bypass the expr cache for lambdas, so probably no?

mypy/mypy/checkexpr.py

Lines 6035 to 6050 in 843d133

elif (
isinstance(node, (CallExpr, ListExpr, TupleExpr, DictExpr, OpExpr))
and not (self.in_lambda_expr or self.chk.current_node_deferred)
and not self.chk.options.disable_expression_cache
):
if (node, type_context) in self.expr_cache:
binder_version, typ, messages, type_map = self.expr_cache[(node, type_context)]
if binder_version == self.chk.binder.version:
self.chk.store_types(type_map)
self.msg.add_errors(messages)
else:
typ = self.accept_maybe_cache(node, type_context=type_context)
else:
typ = self.accept_maybe_cache(node, type_context=type_context)
else:
typ = node.accept(self)

Copy link
Collaborator

@A5rocks A5rocks Nov 3, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes some sense, but I don't quite get the comment there. I also don't get why this extra cache exists...

I guess the comment is saying "the same expr can be evaluated multiple times in different contexts" which makes a bit of sense?

Copy link
Collaborator Author

@sterliakov sterliakov Nov 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also do not fully understand why a separate resolved_type storage is needed at all. It might well be just a remainder that wasn't cleaned up when expr_cache was introduced, but I'm not certain.

This lambda special-casing is coming from in #19408 and #19505, we discovered it independently. lambda exprs are handled in a completely different way with and without type context (see infer_lambda_type_using_context and branching on its result). There's a big difference between accepting a ReturnStmt and its expression alone - supporting both ways essentially means that we use different context stack entries on different paths for the same expression. This part is a bit difficult to reason about, but I still hope I got it correctly...

Copy link
Collaborator

@A5rocks A5rocks Nov 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I guess it would make sense to try removing resolved_type cache in a followup...

return ct

def _first_or_join_fast_item(self, items: list[Type]) -> Type | None:
Expand Down Expand Up @@ -5317,7 +5320,10 @@ def fast_dict_type(self, e: DictExpr) -> Type | None:
self.resolved_type[e] = NoneType()
return None
dt = self.chk.named_generic_type("builtins.dict", [kt, vt])
self.resolved_type[e] = dt
if not self.in_lambda_expr:
# We cannot cache results in lambdas - their bodies can be accepted in
# error-suppressing watchers too early
self.resolved_type[e] = dt
return dt

def check_typeddict_literal_in_context(
Expand Down
14 changes: 14 additions & 0 deletions test-data/unit/check-inference-context.test
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -709,6 +709,20 @@ f(
A(), r=B())
[builtins fixtures/isinstance.pyi]

[case testLambdaWithFastContainerType]
from collections.abc import Callable
from typing import Never, TypeVar

T = TypeVar("T")

def f(a: Callable[[], T]) -> None: ...

def foo(x: str) -> Never: ...

f(lambda: [foo(0)]) # E: Argument 1 to "foo" has incompatible type "int"; expected "str"
f(lambda: {"x": foo(0)}) # E: Argument 1 to "foo" has incompatible type "int"; expected "str"
[builtins fixtures/tuple.pyi]


-- Overloads + generic functions
-- -----------------------------
Expand Down