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
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
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
PEP 498 required f-strings to be recognizable by existing tooling, such as syntax highlighters,
by prohibiting re-using quotes of the same kind and having line breaks inside expression fragments.
We used to detect these problems already at the lexer level, correctly replacing violating quotes
with FSTRING_END token, and appending STATEMENT_BREAK tokens to illegal line breaks inside expressions,
depending on the lexer's state. Now, thanks to a general f-string grammar in PEP 701, most of this
bookkeeping could be moved from the lexer to the CompatibilityVisitor (to still be reported
for previous versions of the language and by the compatibility inspection).
Previously forbidden backslashes and line comments are now also detected by the CompatibilityVisitor
instead of the version-agnostic FStringAnnotator.
One side effect of the new grammar is that parser recovery in pre-3.12 version of Python became
slightly worse. For instance, something like `f'{foo'` used to be recognized as an f-string
with an incomplete fragment lacking its closing brace. Now, it's parsed as an incomplete
f-string, lacking its own closing quote, containing an incomplete string literal inside
an incomplete fragment. What's more, parsing of this fragment's expression doesn't terminate
until the end of a file, because STATEMENT_BREAK is never produced by PythonIndentingProcessor
while it's inside an f-string fragment, and every quote is considered a new string literal.
Examples of parsing tests affected by this are:
PythonParsingTest.testFStringFragmentIncompleteTypeConversionBeforeClosingQuote
PythonParsingTest.testFStringIncompleteFragmentWithTypeConversion
PythonParsingTest.testFStringIncompleteFragment
I also had to simplify some scenarios from PythonHighlightingTest, removing snippets
with incomplete fragments or moving such examples to the very end of a file.
It's not clear how to handle these situations not overcomplicating the lexer.
(cherry picked from commit 03ba6d7fba1b45a84aa92221e6a452645a765205)
IJ-MR-115763
GitOrigin-RevId: cd36470d9cae353fe3caeb2d3b628d8743b46cbb
Report warning if a fixture is used without being passed to test function parameters or to
`@pytest.mark.usefixtures` decorator.
Co-authored-by: Denis Mashutin <Denis.Mashutin@jetbrains.com>
Merge-request: IJ-MR-108713
Merged-by: Egor Eliseev <Egor.Eliseev@jetbrains.com>
GitOrigin-RevId: 28d0711b99ab7ae180f672306dd4ab8a81f1feec
We turned them off as part of PY-48166. Now these stubs are much more complete
and fix a number of problems with the code insight for the library (PY-35164,
PY-37461, PY-50394, PY-59347, PY-60224), most of which are caused by the lack
of information in skeletons automatically generated for its binary modules or
incorrect type information being extracted from docstrings.
I leave the possibility to disable the stubs for the time being and will remove
the registry option once it become clear that they don't cause serious problems.
GitOrigin-RevId: 0df09ddb8ca40f88b908e19c0f49f5b005abaa58
Add new intention and a corresponding quick fix for the usage pd.Series.values property from pandas library.
^DS-4878 Fixed
Merge-request: IJ-MR-106089
Merged-by: Natalia Murycheva <natalia.murycheva@jetbrains.com>
GitOrigin-RevId: 0c8dc40b09ee2d95ecd8ded532f31f5ef4a7740f
Added a new Extension Point for corresponding quick fixes for "Statement without effect inspection." Added QF for Jupyter notebook case and Python file with cells. This QF splits cell just right after the statement without effect
^DS-4558 Fixed
Merge-request: IJ-MR-104455
Merged-by: Natalia Murycheva <natalia.murycheva@jetbrains.com>
GitOrigin-RevId: 7773895cf1ebd6d4e8d56b41e335ec8b97ca5d78
Remove ChainIterable usages from quick documentation and replace with HtmlChunk/HtmlBuilder.
I18ize some fragments.
GitOrigin-RevId: c9b1197efcb17de92361426759a7840ee1be8e4b
PY-33341: Now we render the “Attributes” section in the class documentation, it also allows to describe inherited attributes. (Previously we didn’t render it at all)
PY-56416: In the attribute documentation popup we are able to render attribute description from class docstring. (Previously we took documentation only explicitly from attribute one-line docstring)
PY-33341: We render the “Parameters” section in the class documentation for init parameters, described in the class docstring. (Previously user couldn't use class docstring to describe init parameters)
PY-28900: For the init parameter documentation we take the description from the class docstring if init doesn't have its own docstring. (Previously we took parameter description only from init docstring)
GitOrigin-RevId: d67bf49c72cf7a3634805a6e310c943f1ea848d1
Precise types can be inferred only over AST if it's accessible.
I had to move PyStdlibTypeProvider higher in the provider's hierarchy
so that it could override types coming from Typeshed, otherwise we
infer enum.property type for the "value" attribute.
GitOrigin-RevId: 8727e080cfc06d0edda13eccfd601601dc661da9
Inspection that checks if ClassVar contains type variables which is not allowed
Tests for it
Merge-request: IJ-MR-25493
Merged-by: Daniil Kalinin <Daniil.Kalinin@jetbrains.com>
GitOrigin-RevId: 0fcf81aca7416c04488cf389aba107588561554d
Makes it possible to mark individual TypedDict keys as required or not required, covered in [PEP-655](https://peps.python.org/pep-0655/)
GitOrigin-RevId: 6567fd1009430e37f32924eb29ab8b4a1a17f315
* Dedicated inspections for `ClassVar` variables in variable declarations, variable reassignments, function parameters, local and return variables
* Types of `ClassVar` variables now resolves correctly
* Tests for `ClassVar` inspections
GitOrigin-RevId: 0fd0ef0126ba2c2801ef82bcbeca4ea9b0c48c73
