I had to update PyUtil.updateDocumentUnblockedAndCommitted to work properly
with non-physical files. In turn, it suddenly made an old formatting test
properly apply PyTrailingBlankLinesPostFormatProcessor to its target file.
GitOrigin-RevId: 0c90a3f6000b5f451697b5743930ef1f84a58b63
I had to extract AutoImportLocallyQuickFix because, otherwise, an implicit
reference to "this" of an enclosing class in an inner class prevents the default
preview machinery from working (there is no way to annotate such a field).
GitOrigin-RevId: 82b4e64f19f9fc47c95726e02d3ee9880f1e7278
In Kotlin streams should be not used, in Java extensions() maybe not performant if you in any case traverse the whole extension point
GitOrigin-RevId: 0b2f9df27d9580c22e78f8017b5d21edeb39e8df
In Kotlin streams should be not used, in Java extensions() maybe not performant if you in any case traverse the whole extension point
GitOrigin-RevId: f9ef0ce23617ffc8c89a4fe6df54142b8f6ca7dc
It was caused by function.getNode() in its constructor. The right way to make
it work with PSI stubs is to delegate completely to the wrapped PyFunction.
Just accepting a PyFunctionStub in its constructor is not enough, as a reference
to the original stub owner is saved inside PSI stub-managing logic, hence it's
restored on a different (original) element.
This synthetic element is not used often in our codebase, but this change will
prevent unstubbing problems if additional usages appear eventually.
I stumbled across it while experimenting with returning a PyBoundFunction from
PyResolveUtil.resolveQualifiedNameInScope for PY-53671.
GitOrigin-RevId: 6b205a7eb5dbe764d1b135ddda975574785b25e2
While resolving an aliased method exported from a module, we might lose
the context that it was referenced via instance and hence its first "self"
parameter is already bound and doesn't need to be passed explicitly.
The reason is PyResolveUtil#doResolveQualifiedNameInScope (called in
PyTargetExpressionImpl.multiResolveAssignedValue) performs resolve
over qualified names saved in PSI stubs and returns plain PsiElements
(end results) that don't retain such information about their qualifiers.
QualifiedResolveResult can't be used there either because we don't keep
PyExpressions in PSI stubs. What's more, when later such function is referenced
via some module we consider it definitely unbound, even though a module cannot
possibly have a method as its immediate attribute. I changed the logic so that
we no longer consider referencing a method through a module as somehow affecting
its bound/unbound state.
GitOrigin-RevId: 17a6c3e5d43c088d0663ba54651004c8370d5eca
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
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
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
