language-servers/ruff - Forgejo: Beyond coding. We Forge.

mirror of https://github.com/astral-sh/ruff.git synced 2025-09-29 13:25:17 +00:00

Author	SHA1	Message	Date
Douglas Creager	bdccb37b4a	[ty] Apply function specialization to all overloads (#18020 ) Some checks are pending CI / Determine changes (push) Waiting to run Details CI / cargo fmt (push) Waiting to run Details CI / cargo clippy (push) Blocked by required conditions Details CI / cargo test (linux) (push) Blocked by required conditions Details CI / cargo test (linux, release) (push) Blocked by required conditions Details CI / cargo test (windows) (push) Blocked by required conditions Details CI / cargo test (wasm) (push) Blocked by required conditions Details CI / cargo build (release) (push) Waiting to run Details CI / cargo build (msrv) (push) Blocked by required conditions Details CI / cargo fuzz build (push) Blocked by required conditions Details CI / fuzz parser (push) Blocked by required conditions Details CI / test scripts (push) Blocked by required conditions Details CI / ecosystem (push) Blocked by required conditions Details CI / Fuzz for new ty panics (push) Blocked by required conditions Details CI / cargo shear (push) Blocked by required conditions Details CI / python package (push) Waiting to run Details CI / pre-commit (push) Waiting to run Details CI / mkdocs (push) Waiting to run Details CI / formatter instabilities and black similarity (push) Blocked by required conditions Details CI / test ruff-lsp (push) Blocked by required conditions Details CI / check playground (push) Blocked by required conditions Details CI / benchmarks (push) Blocked by required conditions Details [ty Playground] Release / publish (push) Waiting to run Details Function literals have an optional specialization, which is applied to the parameter/return type annotations lazily when the function's signature is requested. We were previously only applying this specialization to the final overload of an overloaded function. This manifested most visibly for `list.__add__`, which has an overloaded definition in the typeshed: `b398b83631/crates/ty_vendored/vendor/typeshed/stdlib/builtins.pyi (L1069-L1072)` Closes https://github.com/astral-sh/ty/issues/314	2025-05-12 13:48:54 -04:00
Andrew Gallant	346e82b572	ty_python_semantic: add union type context to function call type errors This context gets added only when calling a function through a union type.	2025-05-09 13:40:51 -04:00
Alex Waygood	d1bb10a66b	[ty] Understand classes that inherit from subscripted `Protocol[]` as generic (#17832 )	2025-05-09 17:39:15 +01:00
Alex Waygood	9b694ada82	[ty] Report duplicate `Protocol` or `Generic` base classes with `[duplicate-base]`, not `[inconsistent-mro]` (#17971 )	2025-05-08 23:41:22 +01:00
Charlie Marsh	a2e9a7732a	Update class literal display to use `<class 'Foo'>` style (#17889 ) ## Summary Closes https://github.com/astral-sh/ruff/issues/17238.	2025-05-06 20:11:25 -04:00
Douglas Creager	9085f18353	[ty] Propagate specializations to ancestor base classes (#17892 ) @AlexWaygood discovered that even though we've been propagating specializations to _parent_ base classes correctly, we haven't been passing them on to _grandparent_ base classes: https://github.com/astral-sh/ruff/pull/17832#issuecomment-2854360969 ```py class Bar[T]: x: T class Baz[T](Bar[T]): ... class Spam[T](Baz[T]): ... reveal_type(Spam[int]().x) # revealed: `T`, but should be `int` ``` This PR updates the MRO machinery to apply the current specialization when starting to iterate the MRO of each base class.	2025-05-06 14:25:21 -04:00
Douglas Creager	ada4c4cb1f	[ty] Don't require default typevars when specializing (#17872 ) If a typevar is declared as having a default, we shouldn't require a type to be specified for that typevar when explicitly specializing a generic class: ```py class WithDefault[T, U = int]: ... reveal_type(WithDefault[str]()) # revealed: WithDefault[str, int] ``` --------- Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>	2025-05-05 18:29:30 -04:00
Douglas Creager	47e3aa40b3	[ty] Specialize bound methods and nominal instances (#17865 ) Fixes https://github.com/astral-sh/ruff/pull/17832#issuecomment-2851224968. We had a comment that we did not need to apply specializations to generic aliases, or to the bound `self` of a bound method, because they were already specialized. But they might be specialized with a type variable, which _does_ need to be specialized, in the case of a "multi-step" specialization, such as: ```py class LinkedList[T]: ... class C[U]: def method(self) -> LinkedList[U]: return LinkedList[U]() ``` --------- Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>	2025-05-05 17:17:36 -04:00
Micha Reiser	b51c4f82ea	Rename Red Knot (#17820 )	2025-05-03 19:49:15 +02:00

9 commits