In case of syntactic ambiguity with previous versions of the grammar, such as
"with (expr)" or "with (expr1, expr2)", PyWithStatement is still parsed as
having its own parentheses, not a parenthesized expression or a tuple as
a single context expression. The latter case, even though syntactically legal,
is still reported by the compatibility inspection in Python <3.9.
These changes also include proper formatter and editing support (e.g. not
inserting backslashes on line breaks inside parentheses), as well as
Complete Current Statement, which now takes possible parentheses into account
while inserting a missing colon.
The changes in the formatter are somewhat ad-hoc, intended to minimize the effect
on other constructs. "With" statement is somewhat special in the sense that it's
the first compound statement (having a statement list) with its own list-like
part in parentheses.
Existing tests on with statement processing were expanded and uniformly named.
Co-authored-by: Semyon Proshev <semyon.proshev@jetbrains.com>
GitOrigin-RevId: 15c33e97f177e81b5ed23891063555df016feb05
It also fixes EA-425763 about using incorrect parent and anchor elements
to insert a function generated from a method of a nested class.
GitOrigin-RevId: f9b9da303396eb78c2c12b2750065dbdc0ba70ed
Support type hints and type checking for typing.ParamSpec and typing.Concatenate
(cherry picked from commit 7854b3386ccdffc0091664e0923622cd8c093fc9)
IJ-MR-12970
GitOrigin-RevId: 4578cb463b6ab8fc244766bfaccb122d0e2b7479
PythonIndentingProcessor ensures that INDENT tokens are never inserted at EOF
and before indented comments. Also, parsing of indented blocks is written so
that DEDENT tokens always appear at their end, unless it's EOF, so no need to
report its absence.
GitOrigin-RevId: f4a8270ead3b3d3cae751727e8379c66659913ed
Support | syntax for python unions.
Also support type | None as a new style for Optional.
Fix highlighting unresolved reference issues with | syntax.
Type inference from isinstance and issubclass.
Add quick fix to switch to old-style syntax in earlier python versions (<3.10)
Fix quick documentation to render new syntax.
(cherry picked from commit 6a64ee12c2d8503a0ef102e8b67cb0b95ce77999)
IJ-MR-8400
GitOrigin-RevId: c26b868fc61f26936a3316ec06f78b66d75f6857
All the corresponding PSI elements now have empty interfaces. The API will be
"beefed up" as we start adding actual processing of them in the code insight
(e.g. for the upcoming CFG and inspections).
The trickiest part of the parsing was the recovery. Patterns allow only
a limited subset of expression syntax, but I tried to sensibly consume and report
everything else (not building PSI for it). So that if user starts typing more
general expressions in the midst of a pattern, we still give meaningful error
messages. It seems a likely cause of errors when the feature first rolls out in
Python 3.10.
GitOrigin-RevId: fae40034964e4a25d91dab06a43d3fc07225d9c7
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
* SpecifyTypeInPy3AnnotationsIntention
* ImportFromToImportIntention
* ImportToggleAliasIntention
* ImportToImportFromIntention
* PyGenerateDocstringIntention
* SpecifyTypeInDocstringIntention
Some of them were additionally simplified by replacing their custom
field for an intention's name with the inherited one.
GitOrigin-RevId: 72e4c1b5fe628eca36496d56396ee9e149f5104f
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
