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
PyDefinitionsSearch.java: replace psi element on original element if it is from pyi and then search for overrides, inheritors etc.
PyiUtil.java: recursively get original element while it is in stub (see the comment) and tests testGoToImplementationNameReExportedThroughAssignmentInPyiStub, testGoToImplementationNameReExportedThroughAssignmentInPyiStubTwice
PyUtil.java: make different methods turnDirIntoInitPy, turnDirIntoInitPyi instead of only turnDirIntoInit to handle cases when the same directory contains __init__.pyi and __init__.py files (PY-54620)
GitOrigin-RevId: 8f0d8a8133548e1a9f52f93b42aa9cae2302e8d7
Modules re-exported as attributes are already covered by explicit declarations
for type checkers under "if _typing.TYPE_CHECKING:" in tensorflow/__init__.py
(see https://github.com/tensorflow/tensorflow/pull/54104). Only detached submodules
made available in imports through a module's __path__ manipulations should be
special-cased on our side.
GitOrigin-RevId: 5d5b732a18d06936dd6047150dfee3028f3fc0d4
We turned them off as part of PY-48166. Now these stubs are much more complete
and fix a number of problems with the code insight for the library (PY-35164,
PY-37461, PY-50394, PY-59347, PY-60224), most of which are caused by the lack
of information in skeletons automatically generated for its binary modules or
incorrect type information being extracted from docstrings.
I leave the possibility to disable the stubs for the time being and will remove
the registry option once it become clear that they don't cause serious problems.
GitOrigin-RevId: 0df09ddb8ca40f88b908e19c0f49f5b005abaa58
Leaving current file boundaries to find a boolean value of a @dataclass
decorator argument breaks index locality and might lead to reentrant indexing,
e.g. when we access PySetuptoolsNamespaceIndex to determine if a directory
should be considered a package.
GitOrigin-RevId: e13ee0aec956e89ba69c600c29cd513ac5774762
This is a followup for DS-4508. The issue was caused by the fact
that intellij.python.helpers content is copied using NIO, and to make
it visible for VFS we need to perform refresh of the latter.
Without it, PyTypeShed.directory property cannot find the Typeshed
root and is initialized to null. Then, PythonSdkUpdater.buildSdkPaths
is unable to locate SDK-specific Typeshed roots and set the corresponding
interpreter paths on SDK update. The problem is that VFS refresh requires
a write action and PyTypeShed.directory is accessed under a read action
(e.g. via PyTypeShed.INSTANCE.isInside in PythonLanguageLevelPusher), so
performing an explicit refresh would cause a deadlock (not to mention
that copying files under a read action is generally concerning).
The easiest way to address that is just to resolve to these stubs directly
inside the distribution, as before, not triggering copying them. Such stub
files are not executable by the interpreter and, thus, don't cause the problems
with .pyc files corrupting the IDE installation, so it's safe to leave them
there.
For the time being, Typeshed and python-skeletons are still copied together
with executable helpers, though, but these copies are effectively ignored by
code analysis, It's only not to break the implicit contract of
PythonHelpersLocator.getHelpersRoot, from which it's expected that the entire
content of intellij.python.helpers would reside in the returned directory.
A proper solution would be to move all type hinting stubs from
intellij.python.helpers to a dedicated module, excluded from copying,
but it needs to be further discussed and is risky right before the release.
GitOrigin-RevId: 2470cc110faa8286c44be2102aacc48893ea7ea9
The rules for operators methods are the same as for regular
methods, exercised by other type checkers, i.e. it's assumed
that more specific overloads are defined earlier than less
specific. See e921654e47fe1fc5da047950b70775e342996757 for more
details.
Selecting compatible operator signatures also includes matching
"self" parameter against its expected type, which is necessary
for supporting typing.LiteralString, where some overloads of
"str" methods are made available only for literal strings.
Doing so, however, revealed a few issues with how we track
the direction of operator application, i.e. which operator
methods should be considered "reflected" and have swapped
receiver and argument. We rely on a method's name to decide
but the name is lost when a "reflected" method is defined through
an attribute assignment (PY-61093), and __eq__/__neq__ methods
are bidirectional so their names are not enough (PY-61090).
In PyUnresolvedReferencesInspectionTest.testStubAssignment we
matched C1.__mul__ and in PyTypeTest.testOperatorReturnsAny we
matched int.__eq__, despite the receiver and the argument being swapped,
because both of the methods are declared to accept Any value.
With more precise signature matching both of the tests now fail due to
the aforementioned issues. On the other hand, both of the cases seem rare,
so I disabled them for a while until there is a proper solution.
GitOrigin-RevId: 449a584ca258fe9210f5f2bda453caf9ab4faf7b
The deprecated `PythonHelpersLocator.getHelperPath` used to be cheap and had no I/O, but since bd5183320a43878de861fd11ae1f9bf79710290a it may start to copy many files to another directory. It becomes dangerous to call it from EDT.
GitOrigin-RevId: 98a913e68671b38299791fde7f267a396bd4faa0
Previously, methods PythonHelpersLocator.getHelpersRoot and PythonHelpersLocator.getHelpersProRoot were trivial and had no I/O inside. The things changed in bd5183320a43878de861fd11ae1f9bf79710290a, and it became dangerous to call potentially long operations within locks.
The helpers are used by Code Inside inspections, so it's impossible to move all executions of these functions out of read locks. So, the functions now checks the global progress indicator in order to hold read actions as little as possible.
Also, a logging message is added when calling these functions from EDT. It's not a hard assertion: code that used to work keeps working, but errors about threading are reported now.
GitOrigin-RevId: ae39a6ba6e91a01d2410ede859a0accfb312d758
Previously, PyCharm copied the parent of the helpers' directory. It contained python.jar which has size about 60 MiB and which is not used as a helper.
GitOrigin-RevId: d9cec6ddb93a36dc349af511fbb96221cdb5d951
Python helpers take more than 50 MiB, and copying it lazily on every startup can bring unnecessary performance problems on slow machines.
There's a better approach: copying the helpers into idea.system.path once per installation.
GitOrigin-RevId: 33bcf4eb61463d03480c985014d9e503f94638db
Previously, unresolved class attributes were not reported for the decorated classes because of potential dynamical attributes (see PY-7173). This commit enables this warning again because false-negative unresolved reference warning is much more common and distracting than the case with dynamic attributes
Merge-request: IJ-MR-105254
Merged-by: Daniil Kalinin <Daniil.Kalinin@jetbrains.com>
GitOrigin-RevId: 67d1ab3fe1d5a140836d49f8ef6a65cf01873456
