8 commits

Author	SHA1	Message	Date
Douglas Creager	585ce12ace	[ty] typing.Self is bound by the method, not the class (#19784) ... This fixes our logic for binding a legacy typevar with its binding context. (To recap, a legacy typevar starts out "unbound" when it is first created, and each time it's used in a generic class or function, we "bind" it with the corresponding `Definition`.) We treat `typing.Self` the same as a legacy typevar, and so we apply this binding logic to it too. Before, we were using the enclosing class as its binding context. But that's not correct — it's the method where `typing.Self` is used that binds the typevar. (Each invocation of the method will find a new specialization of `Self` based on the specific instance type containing the invoked method.) This required plumbing through some additional state to the `in_type_expression` method. This also revealed that we weren't handling `Self`-typed instance attributes correctly (but were coincidentally not getting the expected false positive diagnostics).	2025-08-06 17:26:17 -04:00
Douglas Creager	06cd249a9b	[ty] Track different uses of legacy typevars, including context when rendering typevars (#19604) ... This PR introduces a few related changes: - We now keep track of each time a legacy typevar is bound in a different generic context (e.g. class, function), and internally create a new `TypeVarInstance` for each usage. This means the rest of the code can now assume that salsa-equivalent `TypeVarInstance`s refer to the same typevar, even taking into account that legacy typevars can be used more than once. - We also go ahead and track the binding context of PEP 695 typevars. That's _much_ easier to track since we have the binding context right there during type inference. - With that in place, we can now include the name of the binding context when rendering typevars (e.g. `T@f` instead of `T`)	2025-08-01 12:20:32 -04:00
Matthew Mckee	e8ea40012a	[ty] Add generic inference for dataclasses (#18443) ... ## Summary An issue seen here https://github.com/astral-sh/ty/issues/500 The `__init__` method of dataclasses had no inherited generic context, so we could not infer the type of an instance from a constructor call with generics ## Test Plan Add tests to classes.md` in generics folder	2025-06-03 09:59:43 -07:00
David Peter	e67b35743a	[ty] NamedTuple 'fallback' attributes (#18127) ... ## Summary Add various attributes to `NamedTuple` classes/instances that are available at runtime. closes https://github.com/astral-sh/ty/issues/417 ## Test Plan New Markdown tests	2025-05-16 12:56:43 +02:00
David Peter	97d7b46936	[ty] Do not look up __init__ on instances (#18092) ... ## Summary Dunder methods are never looked up on instances. We do this implicitly in `try_call_dunder`, but the corresponding flag was missing in the instance-construction code where we use `member_lookup_with_policy` directly. fixes https://github.com/astral-sh/ty/issues/322 ## Test Plan Added regression test.	2025-05-14 15:33:42 +02:00
Abhijeet Prasad Bodas	235b74a310	[ty] Add more tests for NamedTuples (#17975) ... ## Summary Add more tests and TODOs for `NamedTuple` support, based on the typing spec: https://typing.python.org/en/latest/spec/namedtuples.html ## Test Plan This PR adds new tests.	2025-05-10 10:46:08 +02:00
Alex Waygood	d1bb10a66b	[ty] Understand classes that inherit from subscripted Protocol[] as generic (#17832)	2025-05-09 17:39:15 +01:00
Micha Reiser	b51c4f82ea	Rename Red Knot (#17820)	2025-05-03 19:49:15 +02:00

Renamed from crates/red_knot_python_semantic/resources/mdtest/named_tuple.md (Browse further)