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
As a result code insight will be able to select top priority overloads
And navigation will choose top priority implementations
GitOrigin-RevId: 4c06039ed322eeab427decdcefdf5e1037e20387
Previously we looked for target element with fallback type eval context and resolved global statement received NORMAL rate and didn't filter out.
With code analysis context it receives LOW rate and is removed.
Fix PyRenameTest.testRenameGlobalWithoutToplevel.
GitOrigin-RevId: c8ecdff95c7dfff2e07a027adc9a4bf9e32a7ff7
Fixture.getElementAtCaret goes to target that could be in another file.
And that target could run un-stubbing resolve. Check context constraints and stub presence in PyTargetReference.multiResolve as a result.
Fix PyiTypeTest.testInstanceAttributeAnnotation.
GitOrigin-RevId: f5f505dbcc8ef21aaeaa8edf275b513777924534
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
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
It doesn't use indexes anyhow, and it's very inconvenient not to have it
available while they are being updated. It becomes especially noticeable with
"Idle Indexing" plugin that postpones the indexing on startup.
GitOrigin-RevId: 78dbe4399a38376ae519025e7bbe09906a7d0905
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
