The logic is similar to that for instance attributes. Top-level class
attributes and methods defined in the class body get the precedence,
followed by class attributes defined with assignments in @classmethods
unless the latter would resolve to the same assignments as in
cls.attr = cls.attr + 1
finally, we scan through all other class methods resolving the name
to the first definition inside one of them.
So far, I intentionally didn't expose such attributes in findClassAttribute()
or getClassAttributes() because users of these methods assume that
this API considers only attributes defined immediately in the class body.
Adding extra definitions from class methods might break these usages.
I had to update the inspection about typing.Final, because it relied
on the fact that resolve() on assignment targets on class objects can
lead only to those top-level class attributes, where type hints are normally
located, but now it can lead to assignments to a qualified attribute inside
a containing class method.
GitOrigin-RevId: 0ca5bdaa4efca127ac187e822a49df6795e1028a
Icons removed from SDK package (no need to have a separate class for it), ultimate icons moved out of community module.
There are only 3 icon packages in community:
* `PythonParserIcons`
* `PythonPsiApiIcons`
* `PythonIcons` (aka `intellij.python.community.impl`)
Latter two have `.json` mapper to replace old icons with new one for New UI which is included into corresponding `.xml` file.
GitOrigin-RevId: 0438ad4485b5a82a89c81ec63ae6e575d5bb52de
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
