Skip to content

Conversation

@hauntsaninja
Copy link
Collaborator

@hauntsaninja hauntsaninja commented Jan 31, 2026

In the future, it would be nice to have an option to continue to check unreachable code. See #18707 from A5rocks. This PR lays some semantics preserving groundwork for that.

This is effectively a subset of #18707 , but I go just a little bit further and change the type of TypeMap to exclude None

Btw A5rocks if you are willing to rebase your PR, that would be great. I think --check-unreachable will be a very useful feature.

Co-authored-by: A5rocks

@hauntsaninja hauntsaninja changed the title preserve type info in unreachable branches Preserve narrowing in unreachable code Jan 31, 2026
@github-actions
Copy link
Contributor

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

@hauntsaninja hauntsaninja marked this pull request as ready for review January 31, 2026 05:07
@hauntsaninja hauntsaninja requested a review from A5rocks January 31, 2026 05:08
Copy link
Collaborator

@JukkaL JukkaL left a comment

Choose a reason for hiding this comment

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

Not a full review, but I'm interested if this affects performance.


# The second pass narrows down the types and type checks bodies.
unmatched_types: TypeMap = None
unmatched_types: TypeMap = {s.subject: UninhabitedType()}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Now we construct some extra temporary dictionaries and UninhabitedType objects. Can you measure if this has measurable performance impact?

@hauntsaninja
Copy link
Collaborator Author

hauntsaninja commented Feb 2, 2026

There is maybe some perf impact, something like 0.3% on self check

I think it's well worth the cost. Not checking unreachable code is one of the most surprising mypy behaviours and it's a thing that makes accurately improving narrowing right now quite scary (see e.g. #20660 (comment) or fixing #12535 )

I also do think I can maybe claw some of it back in future refactors

Copy link
Collaborator

@A5rocks A5rocks left a comment

Choose a reason for hiding this comment

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

Makes sense!

If perf really matters, maybe we can replace the dictionaries with an associative list or something like that. Or even a 2-tuple if a function is guaranteed to return at most 1 result! But IMO it's worth it to take a slight perf hit in order to provide new functionality.

@hauntsaninja
Copy link
Collaborator Author

hauntsaninja commented Feb 3, 2026

Yes, I was experimenting with 2-tuples and this is promising (but a larger change). Esp since we actually probably want to switch to combining keyed by literal_hash anyway...

I also recently landed several percentage point improvements, so I feel it is okay if I spend 0.3% :-)

@hauntsaninja hauntsaninja merged commit 606973f into python:master Feb 3, 2026
24 checks passed
@hauntsaninja hauntsaninja deleted the narrow74 branch February 3, 2026 05:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants