1. Determine source element for descriptors with NO_SOURCE recursively.
2. Always provide type abbreviation for type alias constructor
return type.
#KT-15495 Fixed
In this mode, javac AST and Symbol files are used during
Kotlin compilation instead of PSI / binary stuff.
Later, they are reused for Java file compilation.
javac in this mode is integrated into kotlinc.
#KT-16775 Fixed
Exception appears because of different representation of classes without name. For Kotlin we load them with `SpecialNames.NO_NAME_PROVIDED`, but for Java (for light classes) with `SpecialNames.safeIdentifier`
By default we use the fast implementation in CLI compiler,
but in the most of the tests the old one is enabled
Also add tests on CompiledJava with the fast class reading
implementation
See org.jetbrains.kotlin.load.java.structure.impl.classFiles.BinaryJavaClass
as a counter-example, these classes may be used now in CLI too and they
aren't built upon Java PSI
It's only used for CLI compiler, and it should improve performance
of loading Java descriptors from class-files
For IntelliJ, it leads to 10-15% percent speedup of Kotlin Builder
Before this change, we were using a Java model based on Java PSI that
also read class files, but do it less effectively since it performs
some extra work, that we don't need, e.g. eagerly reading all
the inner classes
It seems to be very natural refactoring considering the
following changes: optimizing KotlinCliJavaFileManagerImpl.findClass
to make it read class files manually instead of requesting PSI
Also add a findInnerClass method that can find an inner class
by its name
This change helps to avoid loading all the inner class files
eagerly (that may be rather slow), while all the names are available
in InnerClass attribute
The reason is that canonicalText requires some additional
computations to be done when reading class files, while
in fact we only need a class name of the type
Searching for the single abstract method leads to computing
whole member scopes of given intrefaces, especially when
they contain a lot of methods (i.e. they're definitely not SAMs)
On the other side this method is very hot because it's called
for each Java interface used as a type for some value parameter
(for building SAM adapters)
The idea is to apply some heuristics to understand using only
JavaMethod and supertypes that this interface is definitely not a SAM
Class APIs from java point of view stays the same so we can avoid generating those methods
Otherwise we have to calculate all supertypes when getMethods() is called,
which imposes severe performance penalties
We have to pretend these methods are not 'abstract' (also we consider them 'default' for safety)
so java highlighting does not report "class should be abstract" for all inheritors
We have to manually report "class should be abstract" on some of the java inheritors,
specifically those that are implementing interfaces directly
as opposed to extending kotlin classes implementing those interfaces
Split KotlinPsiElementFinderImpl into two classes: one is used in the
compiler (boolean field isCliFileManager previously handled that), the
other is used in IDE and possibly other non-CLI scenarios.
Also avoid a possible class cast exception in
KotlinJavaPsiFacade.knownClassNamesInPackage
Replace `takeIf { !expr }` with `takeUnless { expr }`.
Cleanup redundant parethesis as in `listOf((expr))`.
Replace `listOf(expr)` with `expr.let(::listOf)` where the former caused significant indentation change.
Alexander Udalov