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
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
The latter method requires index access, and thus might throw IndexNotReady exception
in the dumb mode, and also can return incorrect results for multi-module projects with
several SDKs.
GitOrigin-RevId: c86d6725ef0cd53574fd2986db626e84f3c14328
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
The original idea was just to notify third-party plugin developers that
getCustomStub() and CustomTargetExpressionStubType/PyCustomClassStubType EPs are
not intended for general use. @ApiStatus.Internal is designed exactly for this
purpose.
GitOrigin-RevId: a9a980ddb35a56fd8d84df907c76da498a87a698
It's always applied to Python-specific PSI elements. There is no need to do
a separate cast just to access methods of PsiElement.
GitOrigin-RevId: 481577fa8d2092df7884d6e611622f0bbd4d1e54
This behavior is similar to how mypy and pyright handle overloads relying on
their definition order, where more specific signatures are supposed to precede
more general ones. The subtle difference is that in case of Any arguments,
pyright tries to find a common supertype for return types of all matching
overloads, mypy just returns Any, and we return a union of their return types.
For the time being, it keeps things simple and matches how we treated ambiguous
signatures before.
To make this work, I've had to revise how we handle name redefinitions in files.
Previously, we processed them in the reversed order to give priority to those
later in a file, which is natural for regular .py files. It doesn't make much
sense for .pyi stubs, though, as it's impossible to redefine a name there and
multiple definitions, e.g. overloads, are supposed to have equal precedence.
Now, we don't reverse the order of name definitions in .pyi stubs at all,
and in .py files we do that preserving the original order of overloads.
A side effect of it is that now we always navigate to the first overload
of a name in a .pyi stub, as opposed to the last, but it only seems more
logical and convenient.
On the other hand, when we handle overloads in .py files, we explicitly
assign to them a lower resolve rate to give precedence to implementations.
The only exception is that when there are no implementations we still want
to prefer the latest overload, so we put it into the results second time
with a higher rate. It messed up overloads order important for type inference,
so I've introduced a dedicated RATE_LIFTED_PY_FILE_OVERLOAD rate for such
results to filter them out later in PyCallExpressionHelper. I've also added
a named RATE_PY_FILE_OVERLOAD rate of other overloads in .py files to make
them more easily distinguishable from other resolve results with a low rate.
GitOrigin-RevId: e921654e47fe1fc5da047950b70775e342996757
Existing usages haven't been updated yet not to hinder the upcoming integration
of TypeVarTuple (PY-53105) and LiteralString (PY-58857) support.
GitOrigin-RevId: 16aafd07edfdc98dee0240dce7cd3383b5eb0b00
The snapshots attached by the user indicate that we spend a ridiculous amount of
time collecting a file's import statements in PyResolveUtil.resolveImportedElementQNameLocally
during PSI stubs construction. The reason is that while we skip functions
and classes in a file, we naively scan through all expressions looking for
statements. Now, in this case, we stop the search at statements that cannot
possibly contain other statements. For that I introduced PyCompoundStatement
interface in our PSI hierarchy that also conveniently unifies "match"
statements with other "older" statements directly owning suite.
GitOrigin-RevId: 4282e5367cae4bb1b739ba51242b9719c68018a0
Remove ChainIterable usages from quick documentation and replace with HtmlChunk/HtmlBuilder.
I18ize some fragments.
GitOrigin-RevId: c9b1197efcb17de92361426759a7840ee1be8e4b
Now we have Code Vision hints which determine the author via Git history and show it in the editor automatically, and this information is more accurate than the tags which were automatically added when files were created.
GitOrigin-RevId: f1b80125c2555d89f32aae4e5290d7771a357abf
Now we have Code Vision hints which determine the author via Git history and show it in the editor automatically, and this information is more accurate than the tags which were automatically added when files were created.
GitOrigin-RevId: b442e8499110d543d5ec05b9e07f6c0f88b61ecc
Now we have Code Vision hints which determine the author via Git history and show it in the editor automatically, and this information is more accurate than the tags which were automatically added when files were created.
GitOrigin-RevId: 30586ed1915e3b35394ff3ee6251607c64bbabdd
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
Also fix PY-55231
Add declarationElement field to callable parameter to resolve parameters to class fields in dataclasses
GitOrigin-RevId: ae2703b958061df6f2d74b19920a6e3be2a084f6
Previously, the mapping file was put in a wrong place (not at the root of
a "resources" directory) and was not registered in any plugin descriptor.
However, under debug, the right icon was still displayed because pythonFile.svg
is also remapped in all-platform PlatformIconMappings.json. In actual installers
pythonFile.svg and PlatformIconMappings.json end up in different classloaders,
so this fallback doesn't work.
GitOrigin-RevId: ee361cd7d2d0158b0cc96bd652a5cb53bb7d88c5
