This allows using Symbol API to create references in PyKeywordArgument or PyReferenceExpression elements.
GitOrigin-RevId: 19545edec1499de66fb7744e7f8e3cb7f4ea85d3
In particular:
- Add getters and setters for default types of Type Parameters
- Change the type of declaration elements for Type Parameters from hardcoded PyTargetExpression to PyQualifiedNameOwner to make it possible to set new-style Type Parameters as declaration elements
- Correctly calculate the qualified names of the new-style type alias statements as now they will be used in declaration elements of Type Parameters
GitOrigin-RevId: 5185d85c1a75052dfcb3f97c0eee17b52540d24b
- PEP-696 adds a new syntax for declaring the default types of Type Parameters in new-new style generic classes, functions and type alias statements. Support these grammar changes.
- Store info about default types in stubs for Type Parameters
- Increment the stub version counter in PyFileElementType
GitOrigin-RevId: b6b22e3eaa86ce06132885781e5775a89bf4b840
Added new PyCodeFragmentWithHiddenImports that allows adding imports for unresolved names into a hidden file
GitOrigin-RevId: fb3fa4e491164bdd376d3b25204202034994afa5
This method collects all methods defined in the class and its parents.
Similar to `getPropertiesInherited` and `getClassAttributesInherited`.
GitOrigin-RevId: 8dcec5a002ffa105083ece6f4418d51e6d8c2879
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
