Rename Red Knot (#17820)

crates/ty_python_semantic/resources/mdtest/diagnostics/attribute_assignment.md

@@ -0,0 +1,149 @@
+# Attribute assignment
+
+<!-- snapshot-diagnostics -->
+
+This test suite demonstrates various kinds of diagnostics that can be emitted in a
+`obj.attr = value` assignment.
+
+## Instance attributes with class-level defaults
+
+These can be set on instances and on class objects.
+
+```py
+class C:
+    attr: int = 0
+
+instance = C()
+instance.attr = 1  # fine
+instance.attr = "wrong"  # error: [invalid-assignment]
+
+C.attr = 1  # fine
+C.attr = "wrong"  # error: [invalid-assignment]
+```
+
+## Pure instance attributes
+
+These can only be set on instances. When trying to set them on class objects, we generate a useful
+diagnostic that mentions that the attribute is only available on instances.
+
+```py
+class C:
+    def __init__(self):
+        self.attr: int = 0
+
+instance = C()
+instance.attr = 1  # fine
+instance.attr = "wrong"  # error: [invalid-assignment]
+
+C.attr = 1  # error: [invalid-attribute-access]
+```
+
+## `ClassVar`s
+
+These can only be set on class objects. When trying to set them on instances, we generate a useful
+diagnostic that mentions that the attribute is only available on class objects.
+
+```py
+from typing import ClassVar
+
+class C:
+    attr: ClassVar[int] = 0
+
+C.attr = 1  # fine
+C.attr = "wrong"  # error: [invalid-assignment]
+
+instance = C()
+instance.attr = 1  # error: [invalid-attribute-access]
+```
+
+## Unknown attributes
+
+When trying to set an attribute that is not defined, we also emit errors:
+
+```py
+class C: ...
+
+C.non_existent = 1  # error: [unresolved-attribute]
+
+instance = C()
+instance.non_existent = 1  # error: [unresolved-attribute]
+```
+
+## Possibly-unbound attributes
+
+When trying to set an attribute that is not defined in all branches, we emit errors:
+
+```py
+def _(flag: bool) -> None:
+    class C:
+        if flag:
+            attr: int = 0
+
+    C.attr = 1  # error: [possibly-unbound-attribute]
+
+    instance = C()
+    instance.attr = 1  # error: [possibly-unbound-attribute]
+```
+
+## Data descriptors
+
+When assigning to a data descriptor attribute, we implicitly call the descriptor's `__set__` method.
+This can lead to various kinds of diagnostics.
+
+### Invalid argument type
+
+```py
+class Descriptor:
+    def __set__(self, instance: object, value: int) -> None:
+        pass
+
+class C:
+    attr: Descriptor = Descriptor()
+
+instance = C()
+instance.attr = 1  # fine
+
+# TODO: ideally, we would mention why this is an invalid assignment (wrong argument type for `value` parameter)
+instance.attr = "wrong"  # error: [invalid-assignment]
+```
+
+### Invalid `__set__` method signature
+
+```py
+class WrongDescriptor:
+    def __set__(self, instance: object, value: int, extra: int) -> None:
+        pass
+
+class C:
+    attr: WrongDescriptor = WrongDescriptor()
+
+instance = C()
+
+# TODO: ideally, we would mention why this is an invalid assignment (wrong number of arguments for `__set__`)
+instance.attr = 1  # error: [invalid-assignment]
+```
+
+## Setting attributes on union types
+
+```py
+def _(flag: bool) -> None:
+    if flag:
+        class C1:
+            attr: int = 0
+
+    else:
+        class C1:
+            attr: str = ""
+
+    # TODO: The error message here could be improved to explain why the assignment fails.
+    C1.attr = 1  # error: [invalid-assignment]
+
+    class C2:
+        if flag:
+            attr: int = 0
+        else:
+            attr: str = ""
+
+    # TODO: This should be an error
+    C2.attr = 1
+```

crates/ty_python_semantic/resources/mdtest/diagnostics/invalid_argument_type.md

@@ -0,0 +1,197 @@
+# Invalid argument type diagnostics
+
+<!-- snapshot-diagnostics -->
+
+## Basic
+
+This is a basic test demonstrating that a diagnostic points to the function definition corresponding
+to the invalid argument.
+
+```py
+def foo(x: int) -> int:
+    return x * x
+
+foo("hello")  # error: [invalid-argument-type]
+```
+
+## Different source order
+
+This is like the basic test, except we put the call site above the function definition.
+
+```py
+def bar():
+    foo("hello")  # error: [invalid-argument-type]
+
+def foo(x: int) -> int:
+    return x * x
+```
+
+## Different files
+
+This tests that a diagnostic can point to a function definition in a different file in which an
+invalid call site was found.
+
+`package.py`:
+
+```py
+def foo(x: int) -> int:
+    return x * x
+```
+
+```py
+import package
+
+package.foo("hello")  # error: [invalid-argument-type]
+```
+
+## Many parameters
+
+This checks that a diagnostic renders reasonably when there are multiple parameters.
+
+```py
+def foo(x: int, y: int, z: int) -> int:
+    return x * y * z
+
+foo(1, "hello", 3)  # error: [invalid-argument-type]
+```
+
+## Many parameters across multiple lines
+
+This checks that a diagnostic renders reasonably when there are multiple parameters spread out
+across multiple lines.
+
+```py
+def foo(
+    x: int,
+    y: int,
+    z: int,
+) -> int:
+    return x * y * z
+
+foo(1, "hello", 3)  # error: [invalid-argument-type]
+```
+
+## Many parameters with multiple invalid arguments
+
+This checks that a diagnostic renders reasonably when there are multiple parameters and multiple
+invalid argument types.
+
+```py
+def foo(x: int, y: int, z: int) -> int:
+    return x * y * z
+
+# error: [invalid-argument-type]
+# error: [invalid-argument-type]
+# error: [invalid-argument-type]
+foo("a", "b", "c")
+```
+
+At present (2025-02-18), this renders three different diagnostic messages. But arguably, these could
+all be folded into one diagnostic. Fixing this requires at least better support for multi-spans in
+the diagnostic model and possibly also how diagnostics are emitted by the type checker itself.
+
+## Test calling a function whose type is vendored from `typeshed`
+
+This tests that diagnostic rendering is reasonable when the function being called is from the
+standard library.
+
+```py
+import json
+
+json.loads(5)  # error: [invalid-argument-type]
+```
+
+## Tests for a variety of argument types
+
+These tests check that diagnostic output is reasonable regardless of the kinds of arguments used in
+a function definition.
+
+### Only positional
+
+Tests a function definition with only positional parameters.
+
+```py
+def foo(x: int, y: int, z: int, /) -> int:
+    return x * y * z
+
+foo(1, "hello", 3)  # error: [invalid-argument-type]
+```
+
+### Variadic arguments
+
+Tests a function definition with variadic arguments.
+
+```py
+def foo(*numbers: int) -> int:
+    return len(numbers)
+
+foo(1, 2, 3, "hello", 5)  # error: [invalid-argument-type]
+```
+
+### Keyword only arguments
+
+Tests a function definition with keyword-only arguments.
+
+```py
+def foo(x: int, y: int, *, z: int = 0) -> int:
+    return x * y * z
+
+foo(1, 2, z="hello")  # error: [invalid-argument-type]
+```
+
+### One keyword argument
+
+Tests a function definition with keyword-only arguments.
+
+```py
+def foo(x: int, y: int, z: int = 0) -> int:
+    return x * y * z
+
+foo(1, 2, "hello")  # error: [invalid-argument-type]
+```
+
+### Variadic keyword arguments
+
+```py
+def foo(**numbers: int) -> int:
+    return len(numbers)
+
+foo(a=1, b=2, c=3, d="hello", e=5)  # error: [invalid-argument-type]
+```
+
+### Mix of arguments
+
+Tests a function definition with multiple different kinds of arguments.
+
+```py
+def foo(x: int, /, y: int, *, z: int = 0) -> int:
+    return x * y * z
+
+foo(1, 2, z="hello")  # error: [invalid-argument-type]
+```
+
+### Synthetic arguments
+
+Tests a function call with synthetic arguments.
+
+```py
+class C:
+    def __call__(self, x: int) -> int:
+        return 1
+
+c = C()
+c("wrong")  # error: [invalid-argument-type]
+```
+
+## Calls to methods
+
+Tests that we also see a reference to a function if the callable is a bound method.
+
+```py
+class C:
+    def square(self, x: int) -> int:
+        return x * x
+
+c = C()
+c.square("hello")  # error: [invalid-argument-type]
+```

crates/ty_python_semantic/resources/mdtest/diagnostics/no_matching_overload.md

@@ -0,0 +1,14 @@
+# No matching overload diagnostics
+
+<!-- snapshot-diagnostics -->
+
+## Calls to overloaded functions
+
+TODO: Note that we do not yet support the `@overload` decorator to define overloaded functions in
+real Python code. We are instead testing a special-cased function where we create an overloaded
+signature internally. Update this to an `@overload` function in the Python snippet itself once we
+can.
+
+```py
+type("Foo", ())  # error: [no-matching-overload]
+```

crates/ty_python_semantic/resources/mdtest/diagnostics/semantic_syntax_errors.md

@@ -0,0 +1,221 @@
+# Semantic syntax error diagnostics
+
+## `async` comprehensions in synchronous comprehensions
+
+### Python 3.10
+
+<!-- snapshot-diagnostics -->
+
+Before Python 3.11, `async` comprehensions could not be used within outer sync comprehensions, even
+within an `async` function ([CPython issue](https://github.com/python/cpython/issues/77527)):
+
+```toml
+[environment]
+python-version = "3.10"
+```
+
+```py
+async def elements(n):
+    yield n
+
+async def f():
+    # error: 19 [invalid-syntax] "cannot use an asynchronous comprehension inside of a synchronous comprehension on Python 3.10 (syntax was added in 3.11)"
+    return {n: [x async for x in elements(n)] for n in range(3)}
+```
+
+If all of the comprehensions are `async`, on the other hand, the code was still valid:
+
+```py
+async def test():
+    return [[x async for x in elements(n)] async for n in range(3)]
+```
+
+These are a couple of tricky but valid cases to check that nested scope handling is wired up
+correctly in the `SemanticSyntaxContext` trait:
+
+```py
+async def f():
+    [x for x in [1]] and [x async for x in elements(1)]
+
+async def f():
+    def g():
+        pass
+    [x async for x in elements(1)]
+```
+
+### Python 3.11
+
+All of these same examples are valid after Python 3.11:
+
+```toml
+[environment]
+python-version = "3.11"
+```
+
+```py
+async def elements(n):
+    yield n
+
+async def f():
+    return {n: [x async for x in elements(n)] for n in range(3)}
+```
+
+## Late `__future__` import
+
+```py
+from collections import namedtuple
+
+# error: [invalid-syntax] "__future__ imports must be at the top of the file"
+from __future__ import print_function
+```
+
+## Invalid annotation
+
+This one might be a bit redundant with the `invalid-type-form` error.
+
+```toml
+[environment]
+python-version = "3.12"
+```
+
+```py
+from __future__ import annotations
+
+# error: [invalid-type-form] "Named expressions are not allowed in type expressions"
+# error: [invalid-syntax] "named expression cannot be used within a type annotation"
+def f() -> (y := 3): ...
+```
+
+## Duplicate `match` key
+
+```toml
+[environment]
+python-version = "3.10"
+```
+
+```py
+match 2:
+    # error: [invalid-syntax] "mapping pattern checks duplicate key `"x"`"
+    case {"x": 1, "x": 2}:
+        ...
+```
+
+## `return`, `yield`, `yield from`, and `await` outside function
+
+```py
+# error: [invalid-syntax] "`return` statement outside of a function"
+return
+
+# error: [invalid-syntax] "`yield` statement outside of a function"
+yield
+
+# error: [invalid-syntax] "`yield from` statement outside of a function"
+yield from []
+
+# error: [invalid-syntax] "`await` statement outside of a function"
+# error: [invalid-syntax] "`await` outside of an asynchronous function"
+await 1
+
+def f():
+    # error: [invalid-syntax] "`await` outside of an asynchronous function"
+    await 1
+```
+
+Generators are evaluated lazily, so `await` is allowed, even outside of a function.
+
+```py
+async def g():
+    yield 1
+
+(x async for x in g())
+```
+
+## Rebound comprehension variable
+
+Walrus operators cannot rebind variables already in use as iterators:
+
+```py
+# error: [invalid-syntax] "assignment expression cannot rebind comprehension variable"
+[x := 2 for x in range(10)]
+
+# error: [invalid-syntax] "assignment expression cannot rebind comprehension variable"
+{y := 5 for y in range(10)}
+```
+
+## Multiple case assignments
+
+Variable names in pattern matching must be unique within a single pattern:
+
+```toml
+[environment]
+python-version = "3.10"
+```
+
+```py
+x = [1, 2]
+match x:
+    # error: [invalid-syntax] "multiple assignments to name `a` in pattern"
+    case [a, a]:
+        pass
+    case _:
+        pass
+
+d = {"key": "value"}
+match d:
+    # error: [invalid-syntax] "multiple assignments to name `b` in pattern"
+    case {"key": b, "other": b}:
+        pass
+```
+
+## Duplicate type parameter
+
+Type parameter names must be unique in a generic class or function definition:
+
+```toml
+[environment]
+python-version = "3.12"
+```
+
+```py
+# error: [invalid-syntax] "duplicate type parameter"
+class C[T, T]:
+    pass
+
+# error: [invalid-syntax] "duplicate type parameter"
+def f[X, Y, X]():
+    pass
+```
+
+## `await` outside async function
+
+This error includes `await`, `async for`, `async with`, and `async` comprehensions.
+
+```python
+async def elements(n):
+    yield n
+
+def _():
+    # error: [invalid-syntax] "`await` outside of an asynchronous function"
+    await 1
+    # error: [invalid-syntax] "`async for` outside of an asynchronous function"
+    async for _ in elements(1):
+        ...
+    # error: [invalid-syntax] "`async with` outside of an asynchronous function"
+    async with elements(1) as x:
+        ...
+    # error: [invalid-syntax] "cannot use an asynchronous comprehension outside of an asynchronous function on Python 3.9 (syntax was added in 3.11)"
+    # error: [invalid-syntax] "asynchronous comprehension outside of an asynchronous function"
+    [x async for x in elements(1)]
+```
+
+## Load before `global` declaration
+
+This should be an error, but it's not yet.
+
+TODO implement `SemanticSyntaxContext::global`
+
+```py
+def f():
+    x = 1
+    global x
+```

crates/ty_python_semantic/resources/mdtest/diagnostics/shadowing.md

@@ -0,0 +1,19 @@
+# Shadowing
+
+<!-- snapshot-diagnostics -->
+
+## Implicit class shadowing
+
+```py
+class C: ...
+
+C = 1  # error: [invalid-assignment]
+```
+
+## Implicit function shadowing
+
+```py
+def f(): ...
+
+f = 1  # error: [invalid-assignment]
+```

crates/ty_python_semantic/resources/mdtest/diagnostics/unpacking.md

@@ -0,0 +1,27 @@
+# Unpacking
+
+<!-- snapshot-diagnostics -->
+
+## Right hand side not iterable
+
+```py
+a, b = 1  # error: [not-iterable]
+```
+
+## Exactly too many values to unpack
+
+```py
+a, b = (1, 2, 3)  # error: [invalid-assignment]
+```
+
+## Exactly too few values to unpack
+
+```py
+a, b = (1,)  # error: [invalid-assignment]
+```
+
+## Too few values to unpack
+
+```py
+[a, *b, c, d] = (1, 2)  # error: [invalid-assignment]
+```

crates/ty_python_semantic/resources/mdtest/diagnostics/unresolved_import.md

@@ -0,0 +1,87 @@
+# Unresolved import diagnostics
+
+<!-- snapshot-diagnostics -->
+
+## Using `from` with an unresolvable module
+
+This example demonstrates the diagnostic when a `from` style import is used with a module that could
+not be found:
+
+```py
+from does_not_exist import add  # error: [unresolved-import]
+
+stat = add(10, 15)
+```
+
+## Using `from` with too many leading dots
+
+This example demonstrates the diagnostic when a `from` style import is used with a presumptively
+valid path, but where there are too many leading dots.
+
+`package/__init__.py`:
+
+```py
+```
+
+`package/foo.py`:
+
+```py
+def add(x, y):
+    return x + y
+```
+
+`package/subpackage/subsubpackage/__init__.py`:
+
+```py
+from ....foo import add  # error: [unresolved-import]
+
+stat = add(10, 15)
+```
+
+## Using `from` with an unknown current module
+
+This is another case handled separately in ty, where a `.` provokes relative module name resolution,
+but where the module name is not resolvable.
+
+```py
+from .does_not_exist import add  # error: [unresolved-import]
+
+stat = add(10, 15)
+```
+
+## Using `from` with an unknown nested module
+
+Like the previous test, but with sub-modules to ensure the span is correct.
+
+```py
+from .does_not_exist.foo.bar import add  # error: [unresolved-import]
+
+stat = add(10, 15)
+```
+
+## Using `from` with a resolvable module but unresolvable item
+
+This ensures that diagnostics for an unresolvable item inside a resolvable import highlight the item
+and not the entire `from ... import ...` statement.
+
+`a.py`:
+
+```py
+does_exist1 = 1
+does_exist2 = 2
+```
+
+```py
+from a import does_exist1, does_not_exist, does_exist2  # error: [unresolved-import]
+```
+
+## An unresolvable import that does not use `from`
+
+This ensures that an unresolvable `import ...` statement highlights just the module name and not the
+entire statement.
+
+```py
+import does_not_exist  # error: [unresolved-import]
+
+x = does_not_exist.foo
+```

crates/ty_python_semantic/resources/mdtest/diagnostics/unsupported_bool_conversion.md

@@ -0,0 +1,61 @@
+<!-- snapshot-diagnostics -->
+
+# Different ways that `unsupported-bool-conversion` can occur
+
+## Has a `__bool__` method, but has incorrect parameters
+
+```py
+class NotBoolable:
+    def __bool__(self, foo):
+        return False
+
+a = NotBoolable()
+
+# error: [unsupported-bool-conversion]
+10 and a and True
+```
+
+## Has a `__bool__` method, but has an incorrect return type
+
+```py
+class NotBoolable:
+    def __bool__(self) -> str:
+        return "wat"
+
+a = NotBoolable()
+
+# error: [unsupported-bool-conversion]
+10 and a and True
+```
+
+## Has a `__bool__` attribute, but it's not callable
+
+```py
+class NotBoolable:
+    __bool__: int = 3
+
+a = NotBoolable()
+
+# error: [unsupported-bool-conversion]
+10 and a and True
+```
+
+## Part of a union where at least one member has incorrect `__bool__` method
+
+```py
+class NotBoolable1:
+    def __bool__(self) -> str:
+        return "wat"
+
+class NotBoolable2:
+    pass
+
+class NotBoolable3:
+    __bool__: int = 3
+
+def get() -> NotBoolable1 | NotBoolable2 | NotBoolable3:
+    return NotBoolable2()
+
+# error: [unsupported-bool-conversion]
+10 and get() and True
+```

crates/ty_python_semantic/resources/mdtest/diagnostics/version_related_syntax_errors.md

@@ -0,0 +1,37 @@
+# Version-related syntax error diagnostics
+
+## `match` statement
+
+The `match` statement was introduced in Python 3.10.
+
+### Before 3.10
+
+<!-- snapshot-diagnostics -->
+
+We should emit a syntax error before 3.10.
+
+```toml
+[environment]
+python-version = "3.9"
+```
+
+```py
+match 2:  # error: 1 [invalid-syntax] "Cannot use `match` statement on Python 3.9 (syntax was added in Python 3.10)"
+    case 1:
+        print("it's one")
+```
+
+### After 3.10
+
+On or after 3.10, no error should be reported.
+
+```toml
+[environment]
+python-version = "3.10"
+```
+
+```py
+match 2:
+    case 1:
+        print("it's one")
+```