Previously, extract variable could act on e.g. 'break@outerLoop' and
extract the label, leading into nonsensical 'val x = @outerLoop'.
Prevent JetRefactoringUtil.selectExpression from returning label
expressions to fix this.
#KT-4515 Fixed
Add tests for JetRefactoringUtil.selectExpression, which is invoked by
e.g. extract variable when some text is selected.
Test cases under idea/testData/expressionSelection/ should contain
Kotlin files with the usual <selection> tags, with the expected result
of selectExpression in the last comment of the file.
This keeps behaviour consistent in rare cases when JavaClass can be found but not resolved
As of now this can happen in IDE if we take PsiClass from index but file structure is wrong so we can't resolve the class
Add test which documents this case
The previous commit made JetThisExpression not implement
JetStatementExpression. This had the side effect that
smartSelectExpression over a label-qualified this expression
(e.g 'this@outerClass') would now also list a plain 'this'
as a potential expression. Restore the old behaviour by adding an
explicit check for JetThisExpression.
Operator priority calculation for 'this' expressions was incorrect in
JetPsiUtil.getPriority(): it would return a very low value for
a JetThisExpression, causing the IDE to report that parenthesis
are necessary in an expression like '(this)[1]'.
Fix this by making JetThisExpression not implement
JetStatementExpression by removing the implements clause from
JetLabelQualifiedInstanceExpression and adding it to all other
subclasses of JetLabelQualifiedInstanceExpression.
Fixes KT-4513.
Add test suite for smart expression selector (the small expression list
popup in e.g. Extract Variable.)
The test file format is similar to that in JetNameSuggesterTest: a .kt
file with the usual <caret> marker specifying the place where the smart
selector will be run. Then, the last comment in the file should contain
the expected outcome.
These tests check that that complex references (var p by delegate, for in collection, array[index]) are resolved correctly when target descriptors have type parameters
See 41f9dcba91
#KT-4505 Fixed
Alexey Sedunov