Skip to content
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

[red-knot] Panics on generic type alias #14307

Closed
Tracked by #13478
sharkdp opened this issue Nov 13, 2024 · 1 comment · Fixed by #14312
Closed
Tracked by #13478

[red-knot] Panics on generic type alias #14307

sharkdp opened this issue Nov 13, 2024 · 1 comment · Fixed by #14312
Assignees
Labels
bug Something isn't working red-knot Multi-file analysis & type inference

Comments

@sharkdp
Copy link
Contributor

sharkdp commented Nov 13, 2024

Red knot currently panics when encountering PEP-695 generic type aliases:

type ListOrSet[T] = list[T] | set[T]

Backtrace:

thread '<unnamed>' panicked at crates/red_knot_python_semantic/src/types/infer.rs:872:37:
no entry found for key
stack backtrace:
[…]
   6: red_knot_python_semantic::semantic_index::SemanticIndex::definition
             at ./crates/red_knot_python_semantic/src/semantic_index.rs:210:33
   7: red_knot_python_semantic::types::infer::TypeInferenceBuilder::infer_definition
             at ./crates/red_knot_python_semantic/src/types/infer.rs:872:26
   8: red_knot_python_semantic::types::infer::TypeInferenceBuilder::infer_type_parameters
             at ./crates/red_knot_python_semantic/src/types/infer.rs:4036:50
   9: red_knot_python_semantic::types::infer::TypeInferenceBuilder::infer_type_alias_statement
             at ./crates/red_knot_python_semantic/src/types/infer.rs:1805:13
  10: red_knot_python_semantic::types::infer::TypeInferenceBuilder::infer_statement
             at ./crates/red_knot_python_semantic/src/types/infer.rs:851:53
  11: red_knot_python_semantic::types::infer::TypeInferenceBuilder::infer_body
             at ./crates/red_knot_python_semantic/src/types/infer.rs:831:13
  12: red_knot_python_semantic::types::infer::TypeInferenceBuilder::infer_module
             at ./crates/red_knot_python_semantic/src/types/infer.rs:793:9
  13: red_knot_python_semantic::types::infer::TypeInferenceBuilder::infer_region_scope
             at ./crates/red_knot_python_semantic/src/types/infer.rs:417:17
  14: red_knot_python_semantic::types::infer::TypeInferenceBuilder::infer_region
             at ./crates/red_knot_python_semantic/src/types/infer.rs:405:46
  15: red_knot_python_semantic::types::infer::TypeInferenceBuilder::finish
             at ./crates/red_knot_python_semantic/src/types/infer.rs:4044:9
@sharkdp sharkdp added the red-knot Multi-file analysis & type inference label Nov 13, 2024
@sharkdp sharkdp self-assigned this Nov 13, 2024
@sharkdp
Copy link
Contributor Author

sharkdp commented Nov 13, 2024

Fixing this probably involves understanding type … = … statements as having their own annotation scope (https://docs.python.org/3/reference/compound_stmts.html#generic-type-aliases).

@sharkdp sharkdp added the bug Something isn't working label Nov 13, 2024
sharkdp added a commit that referenced this issue Nov 13, 2024
## Summary

This avoids a panic inside `TypeInferenceBuilder::infer_type_parameters`
when encountering generic type aliases:
```py
type ListOrSet[T] = list[T] | set[T]
```

To fix this properly, we would have to treat type aliases as being their own
annotation scope [1]. The left hand side is a definition for the type parameter
`T` which is being used in the special annotation scope on the right hand side.
Similar to how it works for generic functions and classes.

[1] https://docs.python.org/3/reference/compound_stmts.html#generic-type-aliases


closes #14307

## Test Plan

Added new example to the corpus.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working red-knot Multi-file analysis & type inference
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant