ruff
9ec690b8 - [red-knot] Add support for string annotations (#14151)

Commit
1 year ago
[red-knot] Add support for string annotations (#14151) ## Summary This PR adds support for parsing and inferring types within string annotations. ### Implementation (attempt 1) This is preserved in https://github.com/astral-sh/ruff/pull/14151/commits/6217f48924f8f3f8a3d28c4929fe5aaad4ad0a59. The implementation here would separate the inference of string annotations in the deferred query. This requires the following: * Two ways of evaluating the deferred definitions - lazily and eagerly. * An eager evaluation occurs right outside the definition query which in this case would be in `binding_ty` and `declaration_ty`. * A lazy evaluation occurs on demand like using the `definition_expression_ty` to determine the function return type and class bases. * The above point means that when trying to get the binding type for a variable in an annotated assignment, the definition query won't include the type. So, it'll require going through the deferred query to get the type. This has the following limitations: * Nested string annotations, although not necessarily a useful feature, is difficult to implement unless we convert the implementation in an infinite loop * Partial string annotations require complex layout because inferring the types for stringified and non-stringified parts of the annotation are done in separate queries. This means we need to maintain additional information ### Implementation (attempt 2) This is the final diff in this PR. The implementation here does the complete inference of string annotation in the same definition query by maintaining certain state while trying to infer different parts of an expression and take decisions accordingly. These are: * Allow names that are part of a string annotation to not exists in the symbol table. For example, in `x: "Foo"`, if the "Foo" symbol is not defined then it won't exists in the symbol table even though it's being used. This is an invariant which is being allowed only for symbols in a string annotation. * Similarly, lookup name is updated to do the same and if the symbol doesn't exists, then it's not bounded. * Store the final type of a string annotation on the string expression itself and not for any of the sub-expressions that are created after parsing. This is because those sub-expressions won't exists in the semantic index. Design document: https://www.notion.so/astral-sh/String-Annotations-12148797e1ca801197a9f146641e5b71?pvs=4 Closes: #13796 ## Test Plan * Add various test cases in our markdown framework * Run `red_knot` on LibCST (contains a lot of string annotations, specifically https://github.com/Instagram/LibCST/blob/main/libcst/matchers/_matcher_base.py), FastAPI (good amount of annotated code including `typing.Literal`) and compare against the `main` branch output
Author
Parents
Loading