* 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
...
This PR implements a modification (in preview) to fluent formatting for
method chains: We break _at_ the first call instead of _after_.
For example, we have the following diff between `main` and this PR (with
`line-length=8` so I don't have to stretch out the text):
```diff
x = (
- df.merge()
+ df
+ .merge()
.groupby()
.agg()
.filter()
)
```
## Explanation of current implementation
Recall that we traverse the AST to apply formatting. A method chain,
while read left-to-right, is stored in the AST "in reverse". So if we
start with something like
```python
a.b.c.d().e.f()
```
then the first syntax node we meet is essentially `.f()`. So we have to
peek ahead. And we actually _already_ do this in our current fluent
formatting logic: we peek ahead to count how many calls we have in the
chain to see whether we should be using fluent formatting or now.
In this implementation, we actually _record_ this number inside the enum
for `CallChainLayout`. That is, we make the variant `Fluent` hold an
`AttributeState`. This state can either be:
- The number of call-like attributes preceding the current attribute
- The state `FirstCallOrSubscript` which means we are at the first
call-like attribute in the chain (reading from left to right)
- The state `BeforeFirstCallOrSubscript` which means we are in the
"first group" of attributes, preceding that first call.
In our example, here's what it looks like at each attribute:
```
a.b.c.d().e.f @ Fluent(CallsOrSubscriptsPreceding(1))
a.b.c.d().e @ Fluent(CallsOrSubscriptsPreceding(1))
a.b.c.d @ Fluent(FirstCallOrSubscript)
a.b.c @ Fluent(BeforeFirstCallOrSubscript)
a.b @ Fluent(BeforeFirstCallOrSubscript)
```
Now, as we descend down from the parent expression, we pass along this
little piece of state and modify it as we go to track where we are. This
state doesn't do anything except when we are in `FirstCallOrSubscript`,
in which case we add a soft line break.
Closes#8598
---------
Co-authored-by: Brent Westbrook <36778786+ntBre@users.noreply.github.com>
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
If `import warnings` exists in the file, we will suggest an edit of
`deprecated -> warnings.deprecated` as "qualify warnings.deprecated"
## Test Plan
Should test more cases...
## 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
## Summary
I assume that the class has been renamed or split since this assertion
was created.
## Test Plan
Compiled locally, nothing more. Relying on CI given the triviality of
this change.
* 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.
Douglas Creager
Dylan
Aria Desires
Micha Reiser
Alex Waygood
Dhruv Manilawala
Bhuminjay Soni
Leandro Braga
Peter Law
Charlie Marsh
Simon Lamon
David Peter