Parser was changed so that it no longer produces empty PyWithItem elements
after trailing commas.
GitOrigin-RevId: f730e68644f3444269d65d157b666267755e0d2d
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
The duplication is redundant as the platform implementation is identical to one in the Kotlin standard library. Moreover, it lacks a contract definition, preventing smart casts.
GitOrigin-RevId: ff97be37b183707e5d074ce2e56a90e3e9325d87
Also fix for resolving display function in new versions of IPython
(cherry picked from commit caff9663d783310b13e55d4387e2b36b58e3ac23)
IJ-MR-19104
GitOrigin-RevId: 3f8d28b9464b62545e342acf2ccd0fbe15b9839d
I had to additionally implement toString() for all custom expression stubs
because otherwise the default Object.toString() breaks the platform test
checks on stub tree consistency (new and updated trees have different text).
GitOrigin-RevId: 35cd97df916836d0443b1177bfa5885864010a68
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 now supports running after compiling with JpsBootstrap that makes another modules structure.
GitOrigin-RevId: d3e3a0598d5cabaa436bc7ce7bfec53b3919343a
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
Since we don't want to specify planned removal date anymore, there is no need to use a separate annotation.
GitOrigin-RevId: a047c55475e0f4752a2842577e094fb041c6c05b
