[ty] Emit invalid type form for PEP 695 aliases#24224
[ty] Emit invalid type form for PEP 695 aliases#24224charliermarsh wants to merge 2 commits intomainfrom
Conversation
Typing conformance resultsNo changes detected ✅Current numbersThe percentage of diagnostics emitted that were expected errors held steady at 86.59%. The percentage of expected errors that received a diagnostic held steady at 80.96%. The number of fully passing files held steady at 68/132. |
Memory usage reportMemory usage unchanged ✅ |
|
| Lint rule | Added | Removed | Changed |
|---|---|---|---|
invalid-await |
40 | 0 | 0 |
invalid-return-type |
1 | 0 | 0 |
| Total | 41 | 0 | 0 |
Changes in flaky projects detected. Raw diff output excludes flaky projects; see the HTML report for details.
| type Bad6 = NotRequired[int] # error: [invalid-type-form] "Type qualifiers are not allowed in type alias definitions" | ||
| type Bad7 = ReadOnly[int] # error: [invalid-type-form] "Type qualifiers are not allowed in type alias definitions" | ||
| type Bad8 = InitVar[int] # error: [invalid-type-form] "Type qualifiers are not allowed in type alias definitions" | ||
| # error: [invalid-type-form] "`InitVar` may not be used without a type argument" |
There was a problem hiding this comment.
This isn't great, we don't show this for bad10: TypeAlias = InitVar.
There was a problem hiding this comment.
Fixed by sharing the codepaths.
c6cc70b to
f1293e6
Compare
|
I think there's a much simpler solution here, give me a second. |
|
See #24242. Ideally I think we would do our PEP-613 validation more similarly to how we do our PEP-695 validation, but that throws up other issues... |
|
Just to clarify, you prefer #24242? |
carljm
left a comment
There was a problem hiding this comment.
Functionality looks good here, just some nits about how we name and comment things.
| type Bad1 = ClassVar[str] # error: [invalid-type-form] "Type qualifiers are not allowed in type alias definitions" | ||
| type Bad2 = ClassVar # error: [invalid-type-form] "Type qualifiers are not allowed in type alias definitions" | ||
| type Bad3 = Final[int] # error: [invalid-type-form] "Type qualifiers are not allowed in type alias definitions" | ||
| type Bad4 = Final # error: [invalid-type-form] "Type qualifiers are not allowed in type alias definitions" | ||
| type Bad5 = Required[int] # error: [invalid-type-form] "Type qualifiers are not allowed in type alias definitions" | ||
| type Bad6 = NotRequired[int] # error: [invalid-type-form] "Type qualifiers are not allowed in type alias definitions" | ||
| type Bad7 = ReadOnly[int] # error: [invalid-type-form] "Type qualifiers are not allowed in type alias definitions" | ||
| type Bad8 = InitVar[int] # error: [invalid-type-form] "Type qualifiers are not allowed in type alias definitions" | ||
| type Bad9 = InitVar # error: [invalid-type-form] "Type qualifiers are not allowed in type alias definitions" |
There was a problem hiding this comment.
Do we already have equivalent test for TypeAlias aliases?
| /// Controls the top-level semantics used when interpreting an annotation expression. | ||
| /// | ||
| /// PEP 695 type-alias values mostly reuse annotation-expression inference, but a few | ||
| /// top-level special cases such as bare `InitVar` should behave like alias RHSs rather |
There was a problem hiding this comment.
I don't know what "behave like alias RHSs" means here. Don't we just mean to say that most type qualifier special forms are prohibited in PEP 695 alias right hand sides?
| /// Annotation semantics for `x: TypeAlias = ...`. | ||
| Pep613TypeAlias, |
There was a problem hiding this comment.
This is misleading if treated as parallel to TypeAliasValue. This is not used for "right hand side of a PEP 613 type alias", it's used for annotated assignments, where an annotation of TypeAlias is allowed (vs other annotation contexts where it is not).
Not clear to me entirely if we should name this AnnotatedAssignment or PEP613AnnotationAllowed -- the former emphasizes when it is used, the latter emphasizes what difference it makes. I guess I kind of learn toward the former?
| /// Annotation semantics for `x: TypeAlias = ...`. | |
| Pep613TypeAlias, | |
| /// The annotation of an annotated assignment statement. | |
| AnnotatedAssignment, |
| /// Annotation semantics for `type X = ...`. | ||
| TypeAliasValue, |
There was a problem hiding this comment.
Two nits on naming here: "TypeAlias" suggests PEP 613, if we don't say PEP695, and "Value" mildly suggests "as a value expression", which is not what we're doing here.
| /// Annotation semantics for `type X = ...`. | |
| TypeAliasValue, | |
| /// Annotation semantics for the right-hand-side of `type X = ...`. | |
| PEP695AliasRHS, |
| } | ||
|
|
||
| /// Infer the type of a PEP 695 type alias value. | ||
| pub(super) fn infer_type_alias_value_expression( |
There was a problem hiding this comment.
| pub(super) fn infer_type_alias_value_expression( | |
| pub(super) fn infer_pep_695_alias_rhs( |
|
Oops, had this open in a tab on "changes" view from last night and missed Alex's comments. |
|
Yeah Alex and I have dueling solutions now. Unfortunately I have to assume his is better lol. |
Summary
Closes astral-sh/ty#3150.