* main:
[ty] Document `TY_CONFIG_FILE` (#22001)
[ty] Cache `KnownClass::to_class_literal` (#22000)
[ty] Fix benchmark assertion (#22003)
Add uv and ty to the Ruff README (#21996)
[ty] Infer precise types for `isinstance(…)` calls involving typevars (#21999)
[ty] Use `FxHashMap` in `Signature::has_relation_to` (#21997)
[ty] Avoid enforcing standalone expression for tests in f-strings (#21967)
[ty] Use `title` for configuration code fences in ty reference documentation (#21992)
## Summary
Infer `Literal[True]` for `isinstance(x, C)` calls when `x: T` and `T`
has a bound `B` that satisfies the `isinstance` check against `C`.
Similar for constrained typevars.
closes https://github.com/astral-sh/ty/issues/1895
## Test Plan
* New Markdown tests
* Verified the the example in the linked ticket checks without errors
In https://github.com/astral-sh/ruff/pull/21957, we tried to use
`union_or_intersection_elements_ordering` to provide a stable ordering
of the union and intersection elements that are created when determining
which type a typevar should specialize to. @AlexWaygood [pointed
out](https://github.com/astral-sh/ruff/pull/21551#discussion_r2616543762)
that this won't work, since that provides a consistent ordering within a
single process run, but does not provide a stable ordering across runs.
This is an attempt to produce a proper stable ordering for constraint
sets, so that we end up with consistent diagnostic and test output.
We do this by maintaining a new `source_order` field on each interior
BDD node, which records when that node's constraint was added to the
set. Several of the BDD operators (`and`, `or`, etc) now have
`_with_offset` variants, which update each `source_order` in the rhs to
be larger than any of the `source_order`s in the lhs. This is what
causes that field to be in line with (a) when you add each constraint to
the set, and (b) the order of the parameters you provide to `and`, `or`,
etc. Then we sort by that new field before constructing the
union/intersection types when creating a specialization.
* 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
Douglas Creager
Micha Reiser
David Peter
Charlie Marsh
Alex Waygood
Dhruv Manilawala
Bhuminjay Soni
Simon Lamon