- Move the following from 'deserialization' to 'descriptors':
NotFoundClasses.kt
AdditionalClassPartsProvider.kt
ClassDescriptorFactory.kt
PlatformDependentDeclarationFilter.kt
findClassInModule.kt
- Move the following form 'descriptors' to 'deserialization':
BuiltInSerializerProtocol.kt
builtInsPackageFragmentProvider.kt
- Extract a marker interface from BuiltInsPackageFragment and move its
implementation to 'deserialization'
- Change the type of parameters in PlatformDependentDeclarationFilter
and AdditionalClassPartsProvider to ClassDescriptor
This will help in getting rid of the circular dependency of
'descriptors' <-> 'deserialization'
"Empty" is slightly confusing because although the scope has no declared
symbols, it is not empty: it has a parent scope which can contain
symbols and can have parents as well
According to the spec, "java.se" and every other non-"java.*" module
that exports at least one package without qualification, is a root.
Currently we only support compilation of a single unnamed module, and
apparently unnamed module should read all root modules.
#KT-18180 Fixed
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