Callee is now a receiver for these cases, previously it was `null`.
Callee is not replaced with constructors to have an ability to map it onto self/cls parameters and process `(cls: Type[T], ...) -> T` annotations.
Stay with the previous behaviour for navigation and looking for target element.
GitOrigin-RevId: c0f9894cf50fd5d7fd325f095976d096fb948e89
Modules list has been updated using python on Windows, seems it should be done on all OSes and merged.
GitOrigin-RevId: 621172608fffddc3e830f1133fba89a05d092eba
To avoid possible confusion regarding its target element, the intention is now
suggested only when the caret is inside a literal part of an f-string, not at
any expression it contains.
The conversion affects only the string on which the action was invoked,
including ones in its inner expressions, but not enclosing f-strings. Hence,
converting quotes for an f-string might also change quotes of its inner strings
to preserve the syntactic correctness. Converting quotes for an inner
strings, on the other hand, is possible only if it won't break their parent
f-strings.
GitOrigin-RevId: fb997ac8e26eea728897820f0d94bd84aa9e4491
One of the compelling reasons for that is that, otherwise, they turn into
nullable types in Kotlin visitors introducing redundant checks everywhere.
Consequently, these changes break existing Kotlin implementations that now
have to remove nullable parameters from their overrides, but this is acceptable
since altering nullability annotations preserves binary compatibility,
and existing, not updated plugins will continue to function.
A note about source compatibility breakage will be added to Plugin Dev docs.
GitOrigin-RevId: 2b3549aecfbba9d7e6365d214400c202e10e61d1
Get rid of PyNamedTupleType.DefinitionLevel (finally) and PyOverridingTypeProvider.
PyNamedTupleType is updated here since otherwise we would have to provide parameters for PyNamedTupleType with NT_FUNCTION as a definition level via PyNamedTupleType.getParameters.
Update NumpyDocStringTypeProvider and numpy test data, otherwise it will return `numpy.core.ufunc` as a type for every function having special name.
See NumpyDocStringTypeProvider.getReferenceType.
Return accidentally lost behaviour in PyiUtil.findSimilarElement for classes: don't look for similar element in ancestors.
GitOrigin-RevId: e2410eaa0e0cd5f98e4a86515b4358c140b373e6
Since, in general, the exact value of such literals can't be known statically,
hence it's just not safe to base a refactoring on them.
I've introduced a new method PyStringLiteralExpression#isInterpolated that
detects whether a literal contains any embedded expressions. It might be
useful in other actions that don't properly take f-strings into account yet.
GitOrigin-RevId: 73ee91a175399576a751d3ec4b590a2e7f171e67
It turned out that several existing type providers incorrectly processed PSI
stubs, returning nothing in cases when TypeEvalContext prohibits accessing AST,
but the containing file was already unstubbed, leading to inconsistent "flaky"
analysis results.
Since the pattern for safe accessing AST vs. stubs properly taking into account
both TypeEvalContext constraints and StubBasedPsiElement.getStub() is notoriously
tricky to get right, and it's not the first time to such problem was discovered,
we tried to hide this logic behind a new experimental API -- StubAwareComputation
and migrated those type providers to it. Other code insight parts that need to
operate on stubs, especially custom ones, might follow.
This change is a joint effort with Semyon Proshev who came up with an initial
draft of the new API and updated all the affected type providers.
GitOrigin-RevId: 2ea467d85a6d30e37049edacd5eb4a32768f5252
- Added PyDecorator.getExpression() to reflect that in Python 3.9
an arbitrary expression can be used after "@". Reused it where possible
in the implementation.
- Removed hasPlainReferenceCallee() in favor of existing getQualifiedName().
Updated javadoc for the latter to clarify how it handles non-trivial callees.
- Added PSI stub tests to make sure that right values are still persisted
with the new flexible decorator grammar.
GitOrigin-RevId: 8109b834c8d257c72f6f6e3c0ce5005060a2b971
It works by automatically inserting a trailing comma before a line break in
multiline collection literals. Additionally, a colon is inserted between a key
and a value in dict literals.
Because of the language ambiguity regarding syntax of some incomplete collection
literals, colon is not inserted after the first key of a dict literal
(it's indistinguishable from a set literal with one item), and comma is not
inserted after the first item of a parenthesized tuple (it's indistinguishable
from a parenthesized expression).
The idea was taken from such implementation of Complete Current Statement for
JSON.
GitOrigin-RevId: 49ff9857d8c12476bfa9aacaed0b49faa99810fd
