The original false positive was caused by the protocol NestedSequence in matplotlib
defined as:
class NestedSequence(Protocol[_T_co]):
def __getitem__(self, key: int, /) -> _T_co | NestedSequence[_T_co]: ...
def __len__(self, /) -> int: ...
which was used to annotate parameters of matplotlib.pyplot.plot and was considered
incompatible with the builtin list.
Skipping positional- and keyword-only parameter separators of the expected callable
is a workaround until we have a comprehensive mechanism for matching signatures.
GitOrigin-RevId: 93d8bb4c6c4405d0e24b5f98152a461691f6197e
- Drop support for python 3.5 & 3.6 in compatibility inspection
- Fix and remove some outdated tests
- Remove xmls for long-unsupported python 2.6 & 3.5
- Regenerate versions.xml
- Remove mentions of OS-specific modules
GitOrigin-RevId: 3265dd1de8a4f7a41119e10c95bb705ca5845efe
It's sufficient to promote the type of string literals to Literal['content']
when a type containing a literal type (either Literal or LiteralString) is
expected, since Literal['content'] is always compatible with LiteralString.
(cherry picked from commit 3c9c0b1c451a17b7f56f3376d9e6cd493a770a73)
IJ-MR-112631
GitOrigin-RevId: 92e3ad2da4874e33af22c56d9dd38fd9c8ff871e
Inspection covers such cases:
* Extending typing.Generic in new-style generic classes
* Extending parameterized typing.Protocol in new-style generic classes
* Using generic upper bounds and constraints with type parameters for ParamSpec and TypeVarTuple
* Mixing traditional and new-style type variables
* Using traditional type variables in new-style type aliases
GitOrigin-RevId: 8812959f64d2d87e1b72f713405edb86936220b9
It reports such cases:
* Duplicated type parameter names in type parameter lists
* Wrong number of type var constraints (one or zero) defined with new-style PEP 695 syntax
* Use of constraints for ParamSpec and TypeVarTuple type parameter kinds
GitOrigin-RevId: e0e8e7eb4dcef0c1b56ea49a3527666e3c713d86
Do not resolve type parameters as class members
Tests for the changes above
Co-authored-by: Mikhail Golubev <mikhail.golubev@jetbrains.com>
GitOrigin-RevId: 96309ebedf26d04e375bfa3a5f8ae0bc9257d48f
Inherit PyTypeAliasStatement from PyQualifiedNameOwner to re-use type aliases stack in PyTypingTypeProvider
Various tests for the changes above
Co-authored-by: Mikhail Golubev <mikhail.golubev@jetbrains.com>
GitOrigin-RevId: 242427c6f84c05ec48c94085f20675b8e30f8625
TypeVarTuples, i.e. type parameters, such as *Ts, and unpacked tuples types, i.e.
concrete types, such as *tuple[int, ...], are two independent entities in the type
system. Keeping them both represented as a single type is confusing and introduces
a lot of bookkeeping for accessing their state and filtering out unpacked tuples in
every place where a type parameter is expected.
For cases where both types are applicable, and we need to distinguish them from regular
"non-unpackable" types, PyVariadicType marker interface was introduced.
Also, make the API names more consistent with the PEPs terminology: "unbound" unpacked
tuple types instead of "homogeneous" unpacked tuple types.
GitOrigin-RevId: be77eae46fd78512eaf74d5a9709faacc762e45f
I prefer the notations used for defining a type and rendering it in the IDE not to diverge,
unless there is a strong incentive to do that. Doing that for Callables is already forcing
us to use two different type renderers for Quick Documentation and generating type hints.
GitOrigin-RevId: f6340182bad60d6a7e94156aadc0f17440ee59d5
Previously, we incorrectly inferred generic list and set types parameterized with
types of each element of the corresponding collection literal instead of a union
of those. For instance, for [1, 2] we inferred list[Literal[1], Literal[2]] instead
of list[Literal[1, 2]].
GitOrigin-RevId: 6f222daee871137a5de5589429f78341704c5544
The introduction of TypeVarTuples and the concept of unpacked tuple types made us
revise all the places where we match sequences of types in type inference.
For instance, when matching type parameters and type arguments for generic
specialization in:
* type hints, i.e. xs: MyGeneric[int, str] = MyGeneric()
* constructor invocations, i.e. xs = MyGeneric[int, str]()
* class declarations, i.e. class MyGeneric(Base[T1, T2, str]): ...
* type alias declarations, i.e. MyAlias: TypeAlias = MyGeneric[T, int]
as well as during type matching of all generic types, both normal non-variadic and
existing "built-in" generic variadics in the type system, namely tuples and
Callables.
Previously, this logic was spread across numerous places in PyTypeChecker and
PyTypingTypeProvider, all with their own subtle differences. The first attempt
of PEP 646 support put all the code for uniform matching of type parameters directly
in PyTypeChecker, significantly complicating its already arcane internals.
I've introduced a unified API for that called PyTypeParameterMapping.
It still retains some of the former quirks in form of its Option flags, controlling
in particular how we handle having some of the expected types unmatched
(imagine expecting MyGeneric[T1, T2, *Ts] and receiving MyGeneric[int]),
but I'm planning to gradually eliminate this conditional logic.
The same class is now also responsible for matching parameter types of callables
that already allowed to fix some of the known problems, such as ignoring their
arity (PY-16994), but I'm going to extract a separate API entity for that, since
matching of callable signatures is a much more complicated task involving
compatibility of different types of parameters (positional-only, keyword-only,
defaults, varargs, etc.).
Another positive side effect of these changes is that substitution of type
parameters during type inference became more consistent, and we no longer lose
useful type information by replacing all unbound type parameters with Any. It's
particularly visible in type checker errors where we stopped dropping unbound type
parameters from messages about mismatched parameter-argument types.
Among other improvements in this changeset are proper scoping for
TypeVarTuples, consistent with other type parameters, and recognizing TypeVarTuples
and unpacked tuples in types of *args parameters in function bodies, e.g.
`*args: *Ts` translates to "args" parameter having the type `tuple[*Ts]`.
Confusing PyNoMatchedType used only for reporting of missing arguments for *args
parameters annotated with unpacked tuples in the type checker inspection, e.g.
def f(*args: *tuple[int, str]): ...
f(42) # a type checker error about a missing argument for str
was also removed from the type system in favor of a simpler approach with handling
such errors directly in the inspection. We might need such a general type in
the future, but it has to be well thought-through.
GitOrigin-RevId: 63db6202254205863657f014632d141d340fe147
This way they have access to type parameters of these functions, and PyReferenceImpl.getResultsFromProcessor
can properly perform flow-sensitive resolve for them now that READ instructions for expressions
inside annotations and WRITE instructions for type parameters are in the same CFG. It allowed to
remove all the special logic for type parameters from PyReferenceImpl as well as from
PyUnboundLocalVariableInspection.
I had to special-case these annotations in PyResolveUtil.scopeCrawlUp, though, to "lift" their
original scope back from what ScopeUtil.getScopeOwner returns, making names defined in a class scope,
e.g., nested classes, visible to them.
GitOrigin-RevId: b2e78211565300dbcd7c2e2b246a7a8e14bb0e8f
Both of these are evaluated in the outer scope, e.g., in a scope of a containing class or a module,
with the corresponding instructions already processed there, and were duplicated in the CFG
of function bodies.
GitOrigin-RevId: 4460cbef6446a311f0ab15ffe3407bfbb73286e2
Also, this commit changes the behavior of PyPIPackageUtil, now only one package per name is supported. Motivation:
- it complicates the logic in all usages of the mapping
- There are only 3 cases when it's applicable and in all cases the second package is abandoned.
GitOrigin-RevId: 80fb1e0d28369bdfeb64f6b928ed1b543165d1de
- rename existing TailTypes class to JavaTailTypes
- declare constants in new TailTypes class
- update usages
GitOrigin-RevId: 62484d4a67c291ff5da13fad223b841cb1855eac
Previously, we acknowledged them in PythonIndentingProcessor.adjustBraceLevel, inserting
synthetic STATEMENT_BREAK in front of them to stop recovery in the parser, similarly
to how we handle other kinds of incomplete brackets, but the state inside PyLexerFStringHelper
was not reset, so it kept trying to find matching closing brackets, quotes and interpreting
colons as PyTokenTypes.FSTRING_FRAGMENT_FORMAT_START instead of just PyTokenTypes.COLON.
The state in PyLexerFStringHelper and PythonIndentingProcessor became out of sync, which
led to assertion violations.
It's not an optimal solution, since now these tokens are listed both in
PythonTokenSetContributor.getUnbalancedBracesRecoveryTokens and in Python.flex lexer
specification, and we need to keep them in sync. Also, PythonTokenSetContributor
can provide additional tokens from other languages, such as Cython. But it's simple
and seems "good enough" to patch the problem in the release.
GitOrigin-RevId: 4e156314cc02aba0634d5d9e3008177f49105051
Even though LanguageLevel enum items are already sorted by the corresponding
version, I decided to introduce a dedicated comparator to make sure that the
logic of isOlderThan/isAtLeast is used for compareTo, not the default order of
enums.
GitOrigin-RevId: f1d4845154c9b71e920e2b634ea6339643bf9467
