For normal completion we don't need to track expression types for expressions other than myForPlace
Also changes in myState are much more rare than memory state copying, thus using copy-on-write strategy on myState seems rewarding
Fixes IDEA-183497 Slow completion in somehow long method with workflow
- remove duplicating code;
- now dependencies include all operator expressions for binary, before
the change only left operand dependencies were considered.
Additionally, I did the following:
* re-generated lists of supported/unsupported interpreter modules
* updated test data wherever Python versions appear in warnings
Still need to figure out, though, why _bz2/bz2 modules were not found
for some old versions of Python, hence information about their presense
should be updated by hand in versions.xml.
Add `getOperation()`: `getOperation` differs from
`getOperationTokenType` in that the former should return actual
operation type which will be used for resolve/inference while the latter
is just a shorthand for obtaining token type of `getOperationToken`. In
case of binary expression it is the same as `getOperationTokenType`, in
case of assignment expression there corresponding operator type is
returned.
Pull down getOperationToken() and getOperationTokenType(): there two
methods aren't used via GrOperatorExpression and they should not.
- background: parsing of the function block (with possible await inside) depends on the function's modifiers (whether it has async)
- provide custom ast comparators extension to be used for the language
- then existing js comparator could be called for <script> contents
- correct js comparator for async modifier check
- new extension point is language-based to reduce the possible overhead of searching for the new extensions and asking them (i.e. we do the search once for the file)
- possible old-way cases [with explicit custom comparator in psi builder's user data] could reuse the new method, and even advantage, for the similar cases with embedded contents