-
Notifications
You must be signed in to change notification settings - Fork 1.8k
[ty] Use TDD-based narrowing constraints and support NoReturn narrowing #23109
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
Merged
sharkdp
merged 6 commits into
astral-sh:main
from
alex:alex/ty-narrowing-conditional-terminals
Feb 12, 2026
+670
−1,103
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
2f7e96e
[ty] Use TDD-based narrowing constraints and support NoReturn narrowing
alex ada1084
[ty] Propagate narrowing through always-true if-conditions
alex 038c17c
[ty] Add test cases for narrowing with terminal branches
alex 7536056
[ty] Limit all-places narrowing to prevent exponential blowup
alex 5fd9a9c
[ty] Revert all-places narrowing (keep test cases with TODOs)
alex 9d8c67a
[ty] Address code review feedback on narrowing PR
alex File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -49,3 +49,196 @@ def _(x: int | None): | |
|
|
||
| reveal_type(x) # revealed: int | ||
| ``` | ||
|
|
||
| ## Narrowing is preserved when a terminal branch prevents a path from flowing through | ||
|
|
||
| When one branch of an if/elif/else is terminal (e.g. contains `return`), narrowing from the | ||
| non-terminal branches is preserved after the merge point. | ||
|
|
||
| ```py | ||
| class A: ... | ||
| class B: ... | ||
| class C: ... | ||
|
|
||
| def _(x: A | B | C): | ||
| if isinstance(x, A): | ||
| pass | ||
| elif isinstance(x, B): | ||
| pass | ||
| else: | ||
| return | ||
|
|
||
| # Only the if-branch (A) and elif-branch (B) flow through. | ||
| # The else-branch returned, so its narrowing doesn't participate. | ||
| reveal_type(x) # revealed: B | (A & ~B) | ||
| ``` | ||
|
|
||
| ## Narrowing is preserved with multiple terminal branches | ||
|
|
||
| ```py | ||
| class A: ... | ||
| class B: ... | ||
| class C: ... | ||
| class D: ... | ||
|
|
||
| def _(x: A | B | C | D): | ||
| if isinstance(x, A): | ||
| return | ||
| elif isinstance(x, B): | ||
| pass | ||
| elif isinstance(x, C): | ||
| pass | ||
| else: | ||
| return | ||
|
|
||
| # Only the elif-B and elif-C branches flow through. | ||
| reveal_type(x) # revealed: (C & ~A) | (B & ~A & ~C) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Similarly here I'd naively expect |
||
| ``` | ||
|
|
||
| ## Multiple sequential if-statements don't leak narrowing | ||
|
|
||
| After a complete if/else where both branches flow through (no terminal), narrowing should be | ||
| cancelled out at the merge point. | ||
|
|
||
| ```py | ||
| class A: ... | ||
| class B: ... | ||
| class C: ... | ||
|
|
||
| def _(x: A | B | C): | ||
| if isinstance(x, A): | ||
| pass | ||
| else: | ||
| pass | ||
|
|
||
| # Narrowing cancels out: both paths flow, so type is unchanged. | ||
| reveal_type(x) # revealed: A | B | C | ||
|
|
||
| if isinstance(x, B): | ||
| pass | ||
| else: | ||
| pass | ||
|
|
||
| # Second if-statement's narrowing also cancels out. | ||
| reveal_type(x) # revealed: A | B | C | ||
| ``` | ||
|
|
||
| ## Narrowing after a `NoReturn` call in one branch | ||
|
|
||
| When a branch calls a function that returns `NoReturn`/`Never`, we know that branch terminates and | ||
| doesn't contribute to the type after the if statement. | ||
|
|
||
| ```py | ||
| import sys | ||
|
|
||
| def _(val: int | None): | ||
| if val is None: | ||
| sys.exit() | ||
| reveal_type(val) # revealed: int | ||
| ``` | ||
|
|
||
| This also works when the `NoReturn` function is called in the else branch: | ||
|
|
||
| ```py | ||
| import sys | ||
|
|
||
| def _(val: int | None): | ||
| if val is not None: | ||
| pass | ||
| else: | ||
| sys.exit() | ||
| reveal_type(val) # revealed: int | ||
| ``` | ||
|
|
||
| And for elif branches: | ||
|
|
||
| ```py | ||
| import sys | ||
|
|
||
| def _(val: int | str | None): | ||
| if val is None: | ||
| sys.exit() | ||
| elif isinstance(val, int): | ||
| pass | ||
| else: | ||
| sys.exit() | ||
| reveal_type(val) # revealed: int | ||
| ``` | ||
|
|
||
| ## Narrowing through always-true branches | ||
|
|
||
| When a terminal (`return`) is inside an always-true branch, narrowing propagates through because the | ||
| else-branch is unreachable and contributes `Never` to the union. | ||
|
|
||
| ```py | ||
| def _(x: int | None): | ||
| if True: | ||
| if x is None: | ||
| return | ||
| reveal_type(x) # revealed: int | ||
| reveal_type(x) # revealed: int | ||
| ``` | ||
|
|
||
| ```py | ||
| def _(x: int | None): | ||
| if 1 + 1 == 2: | ||
| if x is None: | ||
| return | ||
| reveal_type(x) # revealed: int | ||
|
|
||
| # TODO: should be `int` (the else-branch of `1 + 1 == 2` is unreachable) | ||
| reveal_type(x) # revealed: int | None | ||
| ``` | ||
|
|
||
| This also works when the always-true condition is nested inside a narrowing branch: | ||
|
|
||
| ```py | ||
| def _(x: int | None): | ||
| if x is None: | ||
| if 1 + 1 == 2: | ||
| return | ||
|
|
||
| # TODO: should be `int` (the inner always-true branch makes the outer | ||
| # if-branch terminal) | ||
| reveal_type(x) # revealed: int | None | ||
| ``` | ||
|
|
||
| ## Narrowing from `assert` should not affect reassigned variables | ||
|
|
||
| When a variable is reassigned after an `assert`, the narrowing from the assert should not apply to | ||
| the new value. | ||
|
|
||
| ```py | ||
| def foo(arg: int) -> int | None: | ||
| return None | ||
|
|
||
| def bar() -> None: | ||
| v = foo(1) | ||
| assert v is None | ||
|
|
||
| v = foo(2) | ||
| # v was reassigned, so the assert narrowing shouldn't apply | ||
| reveal_type(v) # revealed: int | None | ||
| ``` | ||
sharkdp marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| ## Narrowing from `NoReturn` should not affect reassigned variables | ||
|
|
||
| When a variable is narrowed due to a `NoReturn` call in one branch and then reassigned, the | ||
| narrowing should only apply before the reassignment, not after. | ||
|
|
||
| ```py | ||
| import sys | ||
|
|
||
| def foo() -> int | None: | ||
| return 3 | ||
|
|
||
| def bar(): | ||
| v = foo() | ||
| if v is None: | ||
| sys.exit() | ||
| reveal_type(v) # revealed: int | ||
|
|
||
| v = foo() | ||
| # v was reassigned, so any narrowing shouldn't apply | ||
| reveal_type(v) # revealed: int | None | ||
| ``` | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
I'm a bit confused about why this isn't
A | (B & ~A). If we flow through theifwe should just getA, if we flow through theelifwe haveB & ~A-- addingreveal_type(x)inside the branches above confirms. So it's not clear to me why we don't end up with the union of those here.I guess those are equivalent types (and also equivalent to just
A | B?) -- so maybe this is an acceptable (if slightly surprising) transformation that happens due to the TDD implementation?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.
Yes, the root cause of this is the reversed ordering of TDD nodes that we introduced in #20098.
This didn't have any observable side effects for reachability constraints (which evaluate to a ternary answer), but it does play a role for narrowing constraints.
Removing that
.reverse()changes the result here toA | (B & ~A). But it also breaks ~20 other tests. Some of them are just ordering related, but in some other cases, some union-builder simplifications do not seem to trigger which is a bit concerning. I have not investigated more closely, as we probably still need that optimization.