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
Get rid of Kind in JavaPackageFragmentDescriptor and create subclass which exposes additional function
Add method in JavaClassDescriptor to get correponding package fragment
Remove JavaDescriptorResolver from context
Remove LazyJavaClassResolverWithCache
This actually can affect behaviour because JavaResolverCache has slightly different logic (uses CLASS key in BindingContext as opposed to FQNAME_TO_CLASS_DESCRIPTOR)
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.
Previously smartSelectExpression did both the determination of suitable
expressions and displaying the GUI. Separate the actual logic into a new
method, getSmartSelectSuggestions so that smart selection can be tested
in the future.
JetNameSuggesterTest contains useful code for getting the last comment
of a file. Extract it to JetTestUtils.getLastCommentInFile() so other
tests can use it as well.
Make it serialize data for all packages found in sources and not only
KotlinBuiltIns.FQ_NAME, i.e. "jet". This is required to migrate built-ins from
package "jet" to "kotlin"
This is to account for the case of, say
class Function<R> { fun invoke(): R }
it would be a shame to put @Nullable on the return type of the function, and force all callers to check for null,
so we put no annotations
Svetlana Isakova