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
Additionally, I did the following:
* re-generated lists of supported/unsupported interpreter modules
* updated test data wherever Python versions appear in warnings
GitOrigin-RevId: 66fd298e6051bf91fb894e037a877d0b382da337
IdempotenceChecker ensures that several lookup calls in the same psi element provide same list of elements. While it is true for Django, instances of PyCustomMember are different physically, so IdempotenceChecker can't check if they're equal or not.
This change implements equals/hashCode for em to fix it.
GitOrigin-RevId: 8aad569020ae718aeafc737c97f9864fda9d7a69
* Do not provide references for "open" in Django (already done by another code)
* Do not use full resolve for class and functions names. In most cases "resolve", "ManyToMany" and "ModelForm" are imported as-is, not with aliases.
GitOrigin-RevId: 8a0803e6b19482654c91186aa9754ea3d91da282
Implicits are slow.
* defaultContext() now doesn't have em
* implicits are enabled explicitly (no wordplay here!) for certain user-initiated actions and findReferenceAt
* Latter is for navigating to methods/attributes of unknown types
GitOrigin-RevId: 62df6707507584576ea4c193ccf6e7f0c128c5be
