[ty] Add partial support for TypeIs
#18294
Closed
Conversation
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
InSyncWithFoo
requested review from
AlexWaygood,
carljm,
dcreager and
sharkdp
as code owners
Contributor
|
Contributor
Author
|
Regarding the three problems outlined here:
This PR itself has two new issues:
|
Contributor
|
Sorry, didn't realize there was a comment here looking for feedback. (In general I don't see draft PRs in my notifications, and I assume draft PRs are not ready for review, unless I'm pinged by name for comment.)
I think this is a feature, not a bug. The point of
Happy to dig into this tomorrow, if this is the only issue blocking this PR. |
Contributor
Author
|
@carljm Actually, I think I got them:
The only blocking problem left is that the fuzzer says this PR causes new panics. Here's the generated snippet: for name_3 in something:
class name_5[**name_4](name_3):
pass
else:
class name_3[name_5](b'', name_5=name_1):
pass
name_5()
for name_2 in something:
pass
else:
@name_3
def name_3():
pass
(name_3 := f'') and (name_1 := name_2)
assert name_3I reckon this has something to do with the Otherwise, this is ready for review. |
InSyncWithFoo
force-pushed
the
ty-typeis
branch
2 times, most recently
from
7826639 to
5d89050
Compare
Contributor
|
Sorry I didn't get to this sooner; been focused on getting the big attribute-assignment-narrowing PR landed; it's now landed! It looks like this currently has a build issue and needs conflict resolution with main. @InSyncWithFoo let me know if you're able to get it back into shape; if so I can look into the new panic right away. |
carljm
reviewed
Jun 6, 2025
Contributor
carljm
left a comment
carljm
left a comment
There was a problem hiding this comment.
Some initial review comments. Thanks for your work on this!
crates/ty_python_semantic/resources/mdtest/type_properties/is_subtype_of.md
Show resolved
Hide resolved
Comment on lines
+9241
to
+9244
| /// The ID of the scope to which the symbol belongs, | ||
| /// the ID of the symbol itself within that scope, | ||
| /// and the symbol's name. | ||
| symbol_info: Option<(ScopeId<'db>, ScopedSymbolId, String)>, |
Contributor
There was a problem hiding this comment.
Given the scope and the symbol ID, we should be able to look up the symbol name? Also, I'm not sure we need to include the symbol name in the display of a bound TypeIs anyway. So I would remove the String here.
Also, I think this information will be insufficient to properly handle the case where the symbol may be re-bound. I think we will need to store the visible definitions of the symbol here to support that.
| Some(_) => None, | ||
| }; | ||
|
|
||
| // TODO: Handle unions/intersections |
Contributor
There was a problem hiding this comment.
What kind of handling would we expect here? I don't think it's valid to expect narrowing from returning a union where one of the elements is a TypeIs...
Contributor
Author
There was a problem hiding this comment.
True. As for intersections, TypeIs[a, str] & TypeIs[b, int] should have narrowing effect, but I'm not sure if that type is constructable from Python code.
Contributor
Author
|
@carljm Thanks for the heads up. I probably won't be able to work on this earlier than Sunday (June 8th). Also, the reason for the panic was that the same |
Contributor
Author
|
This PR is unsalvageable; I submitted #18589 as replacement. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Summary
Redo of #16314, part of #117.
TypeIs[]is a special form that allows users to define their own narrowing functions. Despite the syntax,TypeIsis not a generic and, on its own, it is meaningless as a type. Officially, a function annotated as returning aTypeIs[T]is a type narrowing function, whereTis called theTypeIsreturn type.A
TypeIs[T]may or may not be bound to a symbol. Only bound types have narrowing effect:A
TypeIs[T]type:Tis fully static.TrueandFalse.In other words, an unbound type have ambiguous truthiness.
It is possible to infer more precise truthiness for bound types; however, that is not part of this change.
TypeIs[T]is a subtype of or otherwise assignable tobool.TypeIsis invariant with respect to theTypeIsreturn type:TypeIs[int]is neither a subtype nor a supertype ofTypeIs[bool]. When ty sees a function marked as returningTypeIs[T], itsreturns will be checked againstboolinstead. ty will also report such functions if they don't accept a positional argument. Addtionally, a type narrowing function call with no positional arguments (e.g.,f()in the example above) will be considered invalid.Test Plan
Markdown tests.