Skip to content

[ty] Fix excess subscript argument inference for non-generic types#24354

Merged
AlexWaygood merged 1 commit intomainfrom
claude/fix-type-subscript-parsing-KU5Jk
Apr 9, 2026
Merged

[ty] Fix excess subscript argument inference for non-generic types#24354
AlexWaygood merged 1 commit intomainfrom
claude/fix-type-subscript-parsing-KU5Jk

Conversation

@AlexWaygood
Copy link
Copy Markdown
Member

@AlexWaygood AlexWaygood commented Apr 1, 2026

Summary

When a non-generic type (like list[int]) is subscripted with excess arguments (e.g., list[int][0]), the excess arguments should be inferred as regular expressions, not type expressions. This prevents spurious "Int literals are not allowed in this context" errors.

The fix checks if the base type has any type variables. If typevars_len == 0, we know it's not a generic type, so excess subscript arguments are inferred using infer_expression() with a default context instead of infer_type_expression(). This allows us to properly handle non-type values in excess subscripts while still reporting the primary error that the type is not subscriptable.

This change also eliminates a duplicate error message in the test case list[int][0], reducing the error count from two to one.

Test Plan

mdtests updated

…on-generic types

In `list[int][0]`, the `[0]` subscript was incorrectly parsed as a type
expression because `infer_explicit_callable_specialization_impl` always
called `infer_type_expression` for excess type arguments. When the type
has no type variables (i.e. is fully specialized), excess arguments
should be inferred as regular expressions instead.

https://claude.ai/code/session_01Kte64hrkmjVtduw18NpToE
@AlexWaygood AlexWaygood added the ty Multi-file analysis & type inference label Apr 1, 2026
@astral-sh-bot
Copy link
Copy Markdown

astral-sh-bot Bot commented Apr 1, 2026

Typing conformance results

No changes detected ✅

Current numbers
The percentage of diagnostics emitted that were expected errors held steady at 86.76%. The percentage of expected errors that received a diagnostic held steady at 81.53%. The number of fully passing files held steady at 70/132.

@astral-sh-bot
Copy link
Copy Markdown

astral-sh-bot Bot commented Apr 1, 2026

Memory usage report

Memory usage unchanged ✅

@astral-sh-bot
Copy link
Copy Markdown

astral-sh-bot Bot commented Apr 1, 2026

ecosystem-analyzer results

Lint rule Added Removed Changed
invalid-await 0 40 0
invalid-return-type 0 1 0
invalid-type-form 0 1 0
Total 0 42 0

Changes in flaky projects detected. Raw diff output excludes flaky projects; see the HTML report for details.

Raw diff:

sympy (https://github.com/sympy/sympy)
- sympy/vector/implicitregion.py:130:49 error[invalid-type-form] Int literals are not allowed in this context in a type expression

Full report with detailed diff (timing results)

@AlexWaygood
Copy link
Copy Markdown
Member Author

This one is purely Claude-authored but I think it's correct? I've stared at it for quite a while now, anyway.

@AlexWaygood AlexWaygood marked this pull request as ready for review April 8, 2026 14:09
@carljm carljm removed their request for review April 8, 2026 15:30
Copy link
Copy Markdown
Contributor

@sharkdp sharkdp left a comment

Choose a reason for hiding this comment

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

I guess this might need to be reworked once we add support for TypeVarTuple, but it looks good for now. Thanks.

@AlexWaygood AlexWaygood merged commit e9ba848 into main Apr 9, 2026
51 checks passed
@AlexWaygood AlexWaygood deleted the claude/fix-type-subscript-parsing-KU5Jk branch April 9, 2026 07:32
ibraheemdev pushed a commit that referenced this pull request Apr 15, 2026
…24354)

## Summary

When a non-generic type (like `list[int]`) is subscripted with excess
arguments (e.g., `list[int][0]`), the excess arguments should be
inferred as regular expressions, not type expressions. This prevents
spurious "Int literals are not allowed in this context" errors.

The fix checks if the base type has any type variables. If `typevars_len
== 0`, we know it's not a generic type, so excess subscript arguments
are inferred using `infer_expression()` with a default context instead
of `infer_type_expression()`. This allows us to properly handle non-type
values in excess subscripts while still reporting the primary error that
the type is not subscriptable.

This change also eliminates a duplicate error message in the test case
`list[int][0]`, reducing the error count from two to one.

## Test Plan

mdtests updated

Co-authored-by: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ty Multi-file analysis & type inference

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants