Now we can infer decorated method's type based on the type or
type hints of their decorators. It is possible to use several
decorators on the method.
GitOrigin-RevId: 22f934ab5be9cb49a4ae65cbd72e17a7d1505778
Namely, their bundled dependencies and tests.
Common names of test and "vendored" roots were collected based on
a base Anaconda interpreter.
Filtration is done over a module/package qualified name in its closest root,
sharing some parts of the implementation with QualifiedNameFinder.
It's likely to also be utilized in the upcoming auto-importing completion
of qualified names.
To make the customization of a search scope easier to use and extend in
the future, I introduced PySearchScopeBuilder API that allows to build
a custom search scope, excluding some irrelevant parts of a Python SDK.
I also updated the set of known standard library tests.
"idlelib/testcode.py" was removed as the only file entry that is
found only in Python 3.3, which we no longer support.
GitOrigin-RevId: 6676c59011d51371639ce24a5ac5c5b56d6b13fb
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
