Makes it possible to mark individual TypedDict keys as required or not required, covered in [PEP-655](https://peps.python.org/pep-0655/)
GitOrigin-RevId: 6567fd1009430e37f32924eb29ab8b4a1a17f315
* Dedicated inspections for `ClassVar` variables in variable declarations, variable reassignments, function parameters, local and return variables
* Types of `ClassVar` variables now resolves correctly
* Tests for `ClassVar` inspections
GitOrigin-RevId: 0fd0ef0126ba2c2801ef82bcbeca4ea9b0c48c73
See ``indirect`` docs for pytest: instead of direct argument it uses fixture, so we must provide fixture return type
GitOrigin-RevId: c144a0e891f61e15f71c9c012fb99a4dd024e76f
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
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
This way we further reduce the number of irrelevant completion items suggested
effectively in every expression context, e.g. not suggesting "parser" and
"calendar" modules for the "ar" prefix, only something like "argparse" or
"array". The same applies to the completion of attributes with unresolved
qualifiers.
GitOrigin-RevId: 7a58053c4744c3d0066c379a4f190ffd09bfabd1
By giving them an explicit priority lower than the default. Unfortunately,
it doesn't remedy the problem with short module names, such as "re" or "sys",
always being on top when they completely match the entered prefix.
At the moment this behavior is hard-coded in the platform and cannot be
altered by language plugins. It's not caused by the "liftShorter" classifier.
Also, explicitly prioritizing various lookup elements has become quite messy
and scattered across PyCompletionWeigher and specific contributors. It begs
to be refactored, but will be addressed separately.
GitOrigin-RevId: d6f6ad06f5d68f3de7b866b8240a95b785604649
By running the completion contributor for non-imported modules after everything
else, including the LegacyCompletionContributor offering names present in
the scope, and filtering out duplicate variants.
GitOrigin-RevId: 98982b2c33d1fc11d70b144de556a6825bd3febc
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
Supersedes the "Asterisk closure can be collapsed to plus closure" inspection which was only available in PhpStorm
GitOrigin-RevId: a63c6fce88b3700cc521e8b113069a4b2b50a3e4
Update all the /refactoring/move test sources according to the new rule - an empty line is always added after the move
(cherry picked from commit c00d1a499fb9849650eb102dd8bb5380165a1eee)
IJ-CR-17177
GitOrigin-RevId: d436af21c20ddd08b78886a333e6f98c71bcc19b
Added test for this case
(cherry picked from commit 4019a7deb4b577eb6a42200fa4758a2624e26896)
IJ-CR-16991
GitOrigin-RevId: 86861f573d66abd3d9100de1ebed59513838a24d
Otherwise PyTargetExpressionImpl.getType can not infer type for a qualifier defined inside function body.
GitOrigin-RevId: 75345218653fc8507cc31498fda7b8f07d4c02c6
I also went through other places where these collections are used and updated
them where needed.
GitOrigin-RevId: d74bcea57e0ab71273837e3c443b600bfd64ff3b
