- `LLFirCombinedKotlinSymbolProvider` combines multiple
`LLFirProvider$SymbolProvider`s. Its advantages are: combined "names
in package" optimization, caching, combined index access, classpath
order disambiguation.
- Scopes can still be optimized with a combined scope instead of a naive
union scope.
^KT-57314 fixed
- If a `KtClassLikeDeclaration` or all `KtFile`s which contain a
callable are already known, they can now be passed to
`LLFirProvider$SymbolProvider` directly. This avoids index accesses in
`providerHelper`.
`MfvcNodeWithSubnodesImpl` has two problems:
- Naming: its name makes one think that the class is inherited from
`MfvcNode` and implements `MfvcNodeWithSubnodes`.However, both
statements are false.
- Semantics: the class only makes unnecessary indirection between its
properties and code of `MfvcNodeWithSubnodes` class
Using of Kotlin reflection for simple operations like bean management is very slow
First time initialization time: 261 ms for `copyBean(K2JVMCompilerArguments())`
Subsequent calls of `copyBean(K2JVMCompilerArguments())` take 1.7 ms per call
Unfortunately compiler argument handling is also used in Kotlin IntelliJ plugin
to parse facet settings. Big projects may have thousands of Kotlin facets
The same `ArgumentUtilsKt.copyProperties` frame is seen across various freezes:
IDEA-252440 2-3 minutes freeze on Kotlin project reimporting in last 203 eap
IDEA-253107 A lot of short freezes (1-3 sec) during Kotlin project development
KTIJ-23501 Make main run configuration detection lighter
KTIJ-22435 Unresponsive UI with 100% cpu
Reflection issue:
KT-56358 KClasses.getMemberProperties takes too much time
This commit replaces all reflection stuff with a simple code generation
Now `K2JVMCompilerArguments().clone()` goes to hard-to-measure time
Result of the `checkNotNull` calls should always be a non-nullable
values.
The simplest idea how to acheive it is adding not-nullable Any bound
to the type parameter declaration.
Existing comment stating about impossibility of such bound seems to be
not 100% correct because it doesn't take into account presence of
definitely-non-nullable X & Any types that allow described case with
nullable generic.
^KT-55804 Fixed
If dispatch receiver is dynamic and call on it is not dynamic that means
that this call was resolved to some specific declaration because of
smartcast. So we should use original type of this declaration as
dispatch receiver during calculation of IdSignature instead of Any
(which came from dynamic type). Otherwise we will have two different
signatures for the same member declaration
^KT-57682 Fixed
this includes:
- isNativeSourceSet
- getCommonSourceSetsForMetadataCompilation
- getPublishedPlatformCompilations
- getHostSpecificSourceSets
- getHostSpecificMainSharedSourceSets
- allPublishableCommonSourceSets
As all of those methods are heavily lifecycle aware and might
return bad values when called to early
^KT-34662 Verification Pending
Marco Pennekamp