Fixed AST for PySubscriptionExpression containing a slice.
Before PySubscriptionExpression.getIndexExpression() returned only the first slice expression (if any).
Also fixed PySliceItem's subtree, so now its children are correctly mapped to lowerBound, upperBound and stride properties.
GitOrigin-RevId: 840af92957d0431679cf7a477866dea76320ca80
* Extract getting wrapping for collections and arg/param lists into a separate method
* Add a test
GitOrigin-RevId: 7ac252e5ab414329951adc61ea0dd29beeb27c04
Stubs for a third-party package are enabled only if:
- this package is actually installed on the project interpreter
- there are neither "<pkg-name>-stub" package, nor "types-<pkg-name>" installed
on the project interpreter (types-<pkg-name> are Typeshed stubs re-published on PyPI).
The latter rule allows users to install more recent versions of stub packages from PyPI.
A few tests that relied on presense of .pyi stubs for some packages were updated to
explicitly add those to SDK roots.
GitOrigin-RevId: 8460c0d3695405f9e5cf0427b05a1f2744055277
And make their setup similar to
testParenthesesAreNotInsertedAfterNamesDefinedAsFunctionsInTypingPy.
typing.py in the test directory has higher priority than typing.pyi in Typeshed,
as a user .py file (see PyResolveImportUtil.Priority), so
PyResolveImportUtil.resolveQualifiedName can't find typing.pyi, and it's not used
in the tests.
GitOrigin-RevId: 3dd51af04f5e5e16e7167dea32b248bca240b18e
This reverts the changes made in eb733982acf0992fbae822d0feb582fb07ad010f
for PY-40233.
The original problem was PyShadowingBuiltinsInspection erroneously reporting
redefining private names declared in builtins.pyi, such as _T, however,
resolving underscored names from all .pyi stubs was prohibited to fix that.
These are considered "stub-only objects" according to the typing spec
(https://typing.readthedocs.io/en/latest/guides/writing_stubs.html#stub-only-objects),
but it doesn't prohibit reusing them in other stubs and in .py files under
an `if typing.TYPE_CHECKING:` guard.
Besides, both Mypy and Pyright resolve such names imported from .pyi stubs without warnings,
so it doesn't make sense to enforce additional visibility restrictions from our side.
Also, I enabled completing such names in other .pyi stubs (but not in .py files).
Previously, in PY-38172 their completion was disabled everywhere.
GitOrigin-RevId: 8340d4dcaf732d18d481bbee824ffdddd2719d3d
Also, don't query LanguageLevel for each element of each instruction,
only once per scope traversal.
This doesn't fix the problem with unreachable definition *inside* blocks under
unmatched version checks, i.e.
if sys.version_info < (3, 8):
Alias = int
expr: Alias # unresolved
but it's a more difficult problem how to handle those consistently with the idea
of unreachable version checks under the *current* interpreter version, and hopefully
it occurs rarer than, say, unresolved top-level imports of common names from typing.
GitOrigin-RevId: 55fd4597c6d0860d290caba15fbf4d313e985a86
Otherwise, we end up with dozens of unintentionally public names such as "s", "i", "k"
even in the standard library (e.g. `this.s` or `pickletools.i`).
Ideally, we should rely on .pyi stubs and the content of `__all__` to offer only explicitly
exposed API, but not every module has any of those two, and it's not clear how to match
.py files and the corresponding .pyi stubs fast enough for completion.
GitOrigin-RevId: 163c472654e60ae63ff893142b8ddb9accc56393
Previously, such names were visible only on so-called "extended" completion,
activated when the hotkey for the basic completion was hit twice. The main reason
was that collecting such variants from indexes was a slow process, and we
didn't want to harm the responsiveness of completion for basic names.
Now it becomes possible thanks to a number of performance optimizations:
* Instead of using three separate indexes for classes, functions and variables,
we use one -- PyExportedModuleAttributeIndex. By definition, it includes only top-level
"importable" names, so we additionally save time by not filtering out irrelevant
entries. Also, it doesn't contain private definitions starting with an underscore.
It might bother some users, but given that the previous completion was used
extremely rarely, and the new one is going to be visible everywhere, it seems
that pruning unlikely entries as much as possible is a fare tradeoff. In the future,
we might enable them back on the "extended" completion if there is a demand.
Also, this index binds its keys to the project (`traceKeyHashToVirtualFileMapping`),
further eliminating useless index lookups.
* Thanks to the recent fixes in the platform (IJPL-265), it's now possible to
simultaneously iterate over all keys in an index and request values for a given key
without deadlocks, which is much faster than eagerly fetching all keys first.
* While scanning through all matching entries from indexes, we terminate
the lookup if the number of items exceeds the size of the lookup list.
We can further reduce this number by adjusting the "ide.completion.variant.limit"
registry value.
* Calculating expensive "canonical" import paths (e.g. "pkg.private.Name" is importable as
"pkg.Name") is offloaded to a background thread thanks to the `withExpensiveRenderer` API.
We still calculate these paths synchronously, though, for names whose raw qualified names
contain components starting with an underscore to decide whether these private names are
publicly re-exported and, hence, should be displayed.
The rest of the work has been put into reducing the number of entries on the list, e.g.
* The prefix under caret is now matched from the beginning of a name, e.g. `Bar<caret>`
matches `BarBaz`, but not `FooBar`.
* We don't suggest imported names clashing with those already available in scope.
* Some kinds of definitions are not suggested in specific contexts, e.g.
functions and variables are not suggested inside patterns and type hints.
* Nothing is suggested at the top-level of a class body, where dangling
reference expressions or calls are not normally expected.
Additionally, we don't suggest names from .pyi stubs at the moment, because
it pollutes the suggestion list with entries coming from the stubs for
third-party packages in Typeshed. We should probably enable them back once
we are able to properly disable Typeshed entries for not installed packages.
Some legacy forms of completion are left in the extended mode. In particular,
qualified names of classes are offered inside string literals only in this mode.
Also, module and package names are suggested only in the extended mode, because
top-level packages and modules are already suggested for the basic completion
by PyModuleNameCompletionContributor.
A few tests in PyClassNameCompletionTest were updated or removed entirely because
* we no longer suggest private names
* we no longer suggest names from private modules not re-exported in a public module
* we no longer suggest names clashing with those already available in scope
* prefix matching policy was changed to start at the beginning of an identifier
The whole feature can be disabled with the option "Suggest importable classes,
functions and variables in basic completion" in settings.
GitOrigin-RevId: 0787d42ce337b73b01a60f0bb7aa434fee43e659
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
Do not resolve type parameters as class members
Tests for the changes above
Co-authored-by: Mikhail Golubev <mikhail.golubev@jetbrains.com>
GitOrigin-RevId: 96309ebedf26d04e375bfa3a5f8ae0bc9257d48f
This way they have access to type parameters of these functions, and PyReferenceImpl.getResultsFromProcessor
can properly perform flow-sensitive resolve for them now that READ instructions for expressions
inside annotations and WRITE instructions for type parameters are in the same CFG. It allowed to
remove all the special logic for type parameters from PyReferenceImpl as well as from
PyUnboundLocalVariableInspection.
I had to special-case these annotations in PyResolveUtil.scopeCrawlUp, though, to "lift" their
original scope back from what ScopeUtil.getScopeOwner returns, making names defined in a class scope,
e.g., nested classes, visible to them.
GitOrigin-RevId: b2e78211565300dbcd7c2e2b246a7a8e14bb0e8f
Since disabling turned out to be controversial. Even in the ticket some users were
against this decision claiming that it heavily annotated code bases it might be necessary
to retain all annotations from inherited method signatures. We need to think of a better
solution for controlling this behavior on case-to-case basis.
GitOrigin-RevId: c68763f0cad23de8975085e9bc8a6fd99013de3b
I had to move addImports to PyClassRefactoringUtil because PySuperMethodCompletionContributor
resides in python-psi-impl and, thus, has no access to PyOverrideImplementUtil.
GitOrigin-RevId: cf2ac19da779977649144b2477bac3f8ae78bbcd
Now during resolve if there is no class/instance attribute with appropriate name explicitly in the class, we will try to find it in the parent classes and resolve there.
GitOrigin-RevId: 52ab5f0ad63cba187457ba3db6107997ede33dee
Previously in docstrings we incorrectly recognized references in 'Attributes' section only as instance attribute references. It led to false positive 'Unresolved reference' on class attributes references in docstrings and wrong resolve when using class and instance attributes with the same names. Now we use ReferenceType.VARIABLE to identify both class and instance attribute references in 'Attributes' section and then resolve them with priority of instance attributes. Also fixed wrong resolve of attributes references to constructor parameters.
GitOrigin-RevId: ea10bfb092472c0ab14b77f06efd93093cfcd684
Test for PY-53200
Better tests for PY-53200
PY-53200 Removed unnecessary test.
`testMethodNamesDoNotDuplicateParameterList` renamed and moved closer to the corresponding ones
Removed test for method names in suggestions restored
GitOrigin-RevId: 51b0721190718c44810c16e198bad583c2af67d0
