Previously, we looked only for __init__.py to detect re-exported names,
ignoring __init__.pyi that could be used for the same purpose in stub
packages.
GitOrigin-RevId: 48bc58789e47d5b9fb814b99722371fdd670ee2d
Previously, we used the corresponding element's presentation for this purpose,
but it showed the shortest qualified name of its module, not necessarily the
"canonical" name that was actually used for importing. For instance, we could
have suggested `ndarray` from `numpy.core._multiarray_umath` but imported it
as `from numpy import ndarray`. It was both misleading and could have led to
duplicate entries for the same symbol among suggestions.
GitOrigin-RevId: abb350feeac9fd212d47dc0943442e0b16b21c9a
Namely, jump from an empty placeholder __init__.py under python_stubs to the
corresponding real package from a library. Climbing up the series of __init__.py's
is necessary to detect where the name is exported, but previously these parallel
hierarchies were not supported.
GitOrigin-RevId: 3e3d5b8175758f03d24454a29e3f5d7fa120423a
It could happen when several augmented assignments are referencing
each over but don't have an ultimate target expression with a higher
resolve priority because of the CFG.
GitOrigin-RevId: 4e908f04103cc131ec48dca95a775406235228a5
Now import elements from the same directory have priority in resolve
over other equally named elements in plain directories and other equally
named elements have priority over same directory modules in ordinary and
namespace packages.
In libraries, the same directory elements should not be resolved in import.
(cherry picked from commit 2b5103dae6ca3828eee7891be248acf99bc7eb56)
IJ-CR-3755
GitOrigin-RevId: 52161f5ba43415d3ceb2ce3dc2122832da2c6197
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
* Fix a dysfunctional assertion, comparing a wrong PSI file.
* Assert that the resolve result is a file or a directory. "os" from the standard
library actually resolves to a directory in Typeshed, so getContainingFile() call
on it led to an NPE.
* Remove __init__.py from the directory where the same directory import is
performed. It better reflects the future policy when imports from explicit
packages have priority of absolute resolve results, while imports from plain
directories have priority of same directory results (see PY-45114).
GitOrigin-RevId: 5262032a38e653ce9114402fbb710aedfd278773
The cache of resolved qualified names is not context aware, so it's not safe to
keep such results in it. The legacy same directory imports in Python 2 have
already been taken into account and excluded, but we forgot to do the same for
recently enabled same directory imports in Python 3 project sources.
GitOrigin-RevId: f8885543ffa34ea652368a4f190210439173bdfc
There are 3 types of directories: plain directories, ordinary packages (with
__init__.py) and PEP 420 namespace packages. There are 3 types of imports:
absolute (from a root), same directory (absolute import from the current
directory when it's not explicitly marked as a root) and relative imports
(imports that start with dot).
Absolute imports are correct in all kinds of directories.
Same directory imports are correct in Python 2 in all cases and in Python 3 if
we have the directory containing the script with this import in Python path at
runtime. Users of Python 3 often face the problem when they can run the script
from the console because the directory containing this script got into Python
path but still have red underline and an unresolved reference error in the same
directory import because PyCharm didn't know that this file will be used as a
program's entry point. Previously, the way to fix such a problem was marking it
as a source root. But this action was not so obvious, especially for newcomers.
With this feature, such imports resolve successfully and now it is not necessary
to mark directories as source roots.
Relative imports are correct only in Python 3 namespace or ordinary packages and
should not be used in plain directories. If we have a relative import in plain
directory we highlight it with a weak warning and suggest 2 ways of fixing that:
marking directory as a namespace package explicitly (with quick fix or with Mark
As | Namespace Package) or changing this import to the same directory import
with a quickfix or manually.
Explicitly marking namespace packages can later be used for automatically
running files from them and ordinary packages with "-m".
The new resolve policy and explicit namespace packages can be disabled with the
Registry flag "python.explicit.namespace.packages".
These changes also address PY-40396. Namely, now any directory with __init__.py
inside or explicitly marked as a namespace package has a package icon,
regardless of its name or parents.
GitOrigin-RevId: 310fa562eb60121243cb6d68386ffc3e45c73245
Both typing.TypeAlias (available only in 3.10) and typing_extensions.TypeAlias
names are supported.
RHS values of assignments annotated with TypeAlias are always retained in
stubs and injected into (if it's a string literal), regardless of whether
they look similar to a well-formed type hint. It seems natural to assume
that if a user employs such as specific marker as "TypeAlias" at all, they
clearly indicate that the value is supposed to be a type.
The inspections "Type hints definitions and usages" and "Final classes, methods
and variables" properly analyse RHS of assignments annotated with TypeAlias.
Type hinting inspection also reports illegal usages of TypeAlias, as it was
done for other special forms in the typing module.
The type of such variables themselves is Any, however they're still displayed
as having the type "TypeAlias" in Quick Documentation to avoid confusion.
GitOrigin-RevId: fab02f6e1060c0994e1d21201768e7b28ba7d9e0
Modules list has been updated using python on Windows, seems it should be done on all OSes and merged.
GitOrigin-RevId: 621172608fffddc3e830f1133fba89a05d092eba
We shouldn't have used function's presentation there to check it's uniqueness,
it includes parameters that we rightfully don't include in the lookup string as
not affecting the import path anyhow.
GitOrigin-RevId: 29c5d231182afb5ebbf71787baea1cd292d82370
I also changed the implementation so that only the very first tokens of
declarations are considered as anchors for method separators. Otherwise,
they start to flicker as their corresponding class and function elements
are often not re-evaluated by LineMarkerProviders on changes in a document.
GitOrigin-RevId: 90488c4bd1c662634c4b6681ce78b1b64c503782
If docorated function has a parameter and the decorator has
an argument with the same name as the parameter then we must not rename
the argument in case of renaming the parameter.
GitOrigin-RevId: ebc5dcf7448080e2762004a2779cd06700c042a8
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
Namely, if such composed literal has nodes with different quotes, convert only
the one directly under the caret. This way we both preserve the old behavior,
when quotes of all individual strings of the literal were converted, and allow
to convert quotes of at least one element if that is not possible.
I've also migrated the intention to newer PyStringElement API that appeared with
the new f-string support.
GitOrigin-RevId: a8592a46e2991b172a205f041cbc3b668e242e8a
The issue itself was fixed, together with PY-32864, in
931d1ea4c09d145e763aed839dcb4acbb3e43ec7.
GitOrigin-RevId: af02861b24165da22722e2ad7891dc674a944472
Some inspection had duplicated messages for their names. Normalized those
to use "INSP.NAME" keys for that purpose and removed unused copies.
Also, one of the messages was used only in a test commented ten years ago.
Got rid of that and the corresponding test data.
GitOrigin-RevId: c859370a8b62079e9e345cd03386da850de28586
It will fix PyTypeTest.testListTypeByModificationsConstructor and PyTypeTest.testDictTypeByModificationConstructor.
Callee has been resolved to overloads for a long time, it's better to filter out unmatched ones instead of calculating the same call type for every overload. Implemented in PyCallExpressionHelper.
Unify inferring call type for subscriptions and calls.
Union types order in test data has been changed since named elements are collected in reversed order in py files.
Repeat PyTypeTest.testCallableInUnion behaviour in PyTypeTest.testSubscriptionOnWeakType.
PyCallExpressionHelper.forEveryScopeTakeOverloadsOtherwiseImplementations has been updated to preserve elements order.
GitOrigin-RevId: f88eacd0a36dd5fbc59447db9dd4484d5a000bc8
