* origin/main:
Fluent formatting of method chains (#21369)
[ty] Avoid stack overflow when calculating inferable typevars (#21971)
[ty] Add "qualify ..." code fix for undefined references (#21968)
[ty] Use jemalloc on linux (#21975)
Update MSRV to 1.90 (#21987)
[ty] Improve check enforcing that an overloaded function must have an implementation (#21978)
Update actions/checkout digest to 8e8c483 (#21982)
[ty] Use `ParamSpec` without the attr for inferable check (#21934)
[ty] Emit diagnostic when a type variable with a default is followed by one without a default (#21787)
* dcreager/source-order-constraints: (30 commits)
clippy
fix test expectations (again)
include source_order in display_graph output
place bounds/constraints first
don't always bump
only fold once
document display source_order
more comments
remove now-unused items
fix test expectation
use source order in specialize_constrained too
document overall approach
more comment
reuse self source_order
sort specialize_constrained by source_order
lots of renaming
remove source_order_for
simpler source_order_for
doc
restore TODOs
...
When we calculate which typevars are inferable in a generic context, the
result might include more than the typevars bound by the generic
context. The canonical example is a generic method of a generic class:
```py
class C[A]:
def method[T](self, t: T): ...
```
Here, the inferable typevar set of `method` contains `Self` and `T`, as
you'd expect. (Those are the typevars bound by the method.) But it also
contains `A@C`, since the implicit `Self` typevar is defined as `Self:
C[A]`. That means when we call `method`, we need to mark `A@C` as
inferable, so that we can determine the correct mapping for `A@C` at the
call site.
Fixes https://github.com/astral-sh/ty/issues/1874
## Summary
- Treat `if TYPE_CHECKING` blocks the same as stub files (the feature
requested in https://github.com/astral-sh/ty/issues/1216)
- We currently only allow `@abstractmethod`-decorated methods to omit
the implementation if they're methods in classes that have _exactly_
`ABCMeta` as their metaclass. That seems wrong -- `@abstractmethod` has
the same semantics if a class has a subclass of `ABCMeta` as its
metaclass. This PR fixes that too. (I'm actually not _totally_ sure we
should care what the class's metaclass is at all -- see discussion in
https://github.com/astral-sh/ty/issues/1877#issue-3725937441... but the
change this PR is making seems less wrong than what we have currently,
anyway.)
Fixes https://github.com/astral-sh/ty/issues/1216
## Test Plan
Mdtests and snapshots
* origin/main: (22 commits)
[ty] Allow gradual lower/upper bounds in a constraint set (#21957)
[ty] disallow explicit specialization of type variables themselves (#21938)
[ty] Improve diagnostics for unsupported binary operations and unsupported augmented assignments (#21947)
[ty] update implicit root docs (#21955)
[ty] Enable even more goto-definition on inlay hints (#21950)
Document known lambda formatting deviations from Black (#21954)
[ty] fix hover type on named expression target (#21952)
Bump benchmark dependencies (#21951)
Keep lambda parameters on one line and parenthesize the body if it expands (#21385)
[ty] Improve resolution of absolute imports in tests (#21817)
[ty] Support `__all__ += submodule.__all__`
[ty] Change frequency of invalid `__all__` debug message
[ty] Add `KnownUnion::to_type()` (#21948)
[ty] Classify `cls` as class parameter (#21944)
[ty] Stabilize rename (#21940)
[ty] Ignore `__all__` for document and workspace symbol requests
[ty] Attach db to background request handler task (#21941)
[ty] Fix outdated version in publish diagnostics after `didChange` (#21943)
[ty] avoid fixpoint unioning of types containing current-cycle Divergent (#21910)
[ty] improve bad specialization results & error messages (#21840)
...
We now allow the lower and upper bounds of a constraint to be gradual.
Before, we would take the top/bottom materializations of the bounds.
This required us to pass in whether the constraint was intended for a
subtyping check or an assignability check, since that would control
whether we took the "restrictive" or "permissive" materializations,
respectively.
Unfortunately, doing so means that we lost information about whether the
original query involves a non-fully-static type. This would cause us to
create specializations like `T = object` for the constraint `T ≤ Any`,
when it would be nicer to carry through the gradual type and produce `T
= Any`.
We're not currently using constraint sets for subtyping checks, nor are
we going to in the very near future. So for now, we're going to assume
that constraint sets are always used for assignability checks, and allow
the lower/upper bounds to not be fully static. Once we get to the point
where we need to use constraint sets for subtyping checks, we will
consider how best to record this information in constraints.
## Summary
This PR makes explicit specialization of a type variable itself an
error, and the result of the specialization is `Unknown`.
The change also fixes https://github.com/astral-sh/ty/issues/1794.
## Test Plan
mdtests updated
new corpus test
---------
Co-authored-by: Carl Meyer <carl@astral.sh>
## Summary
This PR takes the improvements we made to unsupported-comparison
diagnostics in https://github.com/astral-sh/ruff/pull/21737, and extends
them to other `unsupported-operator` diagnostics.
## Test Plan
Mdtests and snapshots
Douglas Creager
Micha Reiser
Alex Waygood
Dhruv Manilawala
Bhuminjay Soni
Charlie Marsh
Simon Lamon
David Peter
Shunsuke Shibayama