Use ContinuationIndent instead of ContinuationIndentWithoutFirst
for its operands and operators instead. This way we don't over-indent
a condition in parentheses when the opening bracket is on its own line.
Also test that binary expressions in other positions are not
over-indented thanks to the use of ContinuationWithoutFirst for them.
in order to the structure of nested binary expressions during
formatting. For instance, "x and y or z" and "x or y and z" should
be formatted the same regardless of the precedence of individual
operations.
It doesn't affect new imports received as a result of joining several
existing ones sharing the same source. For them user must explicitly
set preferred type of formatting in code style settings.
The cause of the problem was the difference in parsing for different
language levels.
This commit improves error recovery and adds support for stubs for
syntax elements unavailable in older Python versions.
Cases that are covered are necessary for stubs generation
for Python 3.6 standard library. They are discovered by automatic
validation executed by stubs generator in StubsGenerator.kt.
Those are the cases that were fixed:
* A stub for single star argument in Py2 was absent
* Type annotations in Py2 were absent
* Print with end argument in Py2 broke parser
* Exec function as argument in Py2 broke parser
* Async keyword after decorator broke parser
All the cases are listed as test cases in PyUnifiedStubsTest
P.S. It is possible though that more cases will be revealed in future.
If in the frame there is at least one very long or slow variable, the frame's variable aren't shown. In order to avoid such situations we add an option to load variables asynchronously. At first debugger loads only names of the variables, and after that it sends additional commands and evaluates values of the variables in a separate threads.
So that other annotations, such as the one for builtin symbols, always
have priority over it, but it still was possible to, say, add
a background color or a font style for type annotations using this new
settings.
So far they're called "function calls" and "method calls" respectively,
though strictly speaking, these are rather "unqualified calls" and
"qualified calls" because we don't distinguish between function and
constructor calls, as well as method and qualified function calls
to avoid costs of proper resolving in the highlighting pass.
that is the same as for the opening comment. Otherwise, it's impossible
to detect the necessary indentation in languages like Python, where the
block containing a comment is itself determined by this very indentation.
If it's wrong for some reason, the subsequent call of
CodeStyleManager.adjustLineIndent() should handle that in all other
languages.
Semyon Proshev
Mikhail Golubev
fitermayandAndrey Vlasovskikh
Ilya.Kazakevich
Dmitry Trofimov
Elizaveta Shashkova