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
Parser was changed so that it no longer produces empty PyWithItem elements
after trailing commas.
GitOrigin-RevId: f730e68644f3444269d65d157b666267755e0d2d
Since we don't want to specify planned removal date anymore, there is no need to use a separate annotation.
GitOrigin-RevId: a047c55475e0f4752a2842577e094fb041c6c05b
