BaseCompilerSettings.validateInheritedFieldsUnchanged() compares
old and new properties of the compiler settings, and the check requires
ArgumentParseErrors.equals() to be correctly implemented
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
The reason is that searching for a class in a VirtualFile-based
directory (i.e. in a package) happens for O(|amount-of-files-in-dir|),
and it may be rather crucial for packages with a huge amount
of classes
Note that it was checked that the cache should not take a lot of heap
since we call findClass only for really existing classes:
see org/jetbrains/kotlin/load/java/lazy/descriptors/LazyJavaPackageScope.kt:48
For example, there are no more than 10k classes for the whole
intelliJ project (but the cache is flushed for each module)
It's important because even if we know the root where
the package is located we need to go through its parts,
and it's not as fast as it could be since implementation
of VirtualFile.findChild() traverse all files in the directory
to find the relevant one
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
This is not needed anymore because we use a special TypeCheckerContext
which correctly matches header class to impl typealias.
Also fix 'platformModule' in areCompatibleClassifiers: it's not b's
module (b is already the expansion of a typealias), but the module of
"other", original 'impl' classifier
Also do not call isHeader/isImpl because the returned declarations are
guaranteed to be isHeader in findCompatibleHeaderForImpl and isImpl in
findCompatibleImplForHeader
Build the compatibility map when looking for header given an impl, in
the same way as it's done for the search of impl given a header. The map
is mostly unused now (only its value at key=Compatible is used), but
will be used in the future to improve the diagnostic messages here
rename source-sections compiler plugin jar in the dist (add kotlin- prefix),
according to the agreed naming scheme for the artefacts. (The renaming of the
other plugins should follow.)
in addition configure proguard to retain VirtualFile members, since they
are used in the source-sections plugin
use it from the installed plugin for dependent modules (frontend)
use it from bootstrap in the plugin being built
also drop unused daemon-client from the plugin
This makes it consistent with ant build and allow building idea project
without prior ant dist
Currently kotlin-stdlib-common doesn't have serialized built-ins inside,
so in a multiplatform project, it was possible that either JVM or JS
built-ins (depending on the order of entries in the project
configuration) were going to be used for the analysis of a common module
depending on kotlin-stdlib-common. This resulted, for example, in
additional built-in member calls (e.g. "List.stream()") being unresolved
in JVM modules when they used the List instance coming from the common
module (see the added test)
Now it's possible to do find usages for other languages when light
elements are used.
Revert efb36f4a49 and revise fix of KT-7983:
Don't consider local and non-local class with same fqn equivalent.
#KT-7983 Fixed
Applying plugins leads to failures when matching members in LazyLightClassDataHolder
because plugins rely on analysis results
This decision has its drawbacks (java won't see results of plugin execution)
but more work on light classes is needed if we want to support this usecase
We can argue that plugins should only generate synthetic members
but there is no such restriction atm
Otherwise any cached reference to light class can lead to severe memory leaks in IDE
since LightClassBuiderResult holds GenerationState which holds ModuleDescriptor
Don't use coroutine facade in following cases:
* When calling coroutine functions in non-suspend mode (i.e.
suspend flag is either false or skipped).
* When passing continuation from suspend function to suspend function.
Use facade only for corresponding intrinsics.
Reason: interceptor should not be called on each suspend function
invocation, it should be called after resume from innermost
suspend function.
Fix KT-17067. The example provided with the issue is very similar to
dispatchResume.kt which passes after these changes.
Add test to prove that KT-17446 is no more reproducible.
Dmitry Jemerov