TypeRegistry is the static map which contains mapping between type of
session component and its index in the session array. Originally
`KClass` of a component was used as a key in this map, which worked
pretty well for compiler components. But there was a problem with
components from plugins and Kotlin daemon: in compilation with daemon
we keep TypeRegistry between compilations. But for each compilation
we load plugins from jar, which brings to the situation when after N
compilations there is N entries in TypeRegistry map with different
KClass'es for same extension component. This not only causes AIOBE
but also introduces the memory leak, because we keep reference to
KClass which is not used anymore
So to fix this issue it's enough to just store FQN of component in
TypeRegistry instead of KClass
There are no tests in this commit, but they will be added in next
commit relevant to scripting. With those commits we will have gradle
integration tests which uses Kotlin compiler daemon and registers
a compiler plugin for scripting
^KT-55023 Fixed
If a certain type statement is true on loop entry and all continue
paths, then it is also true on exit if the condition did not reassign
the variable.
^KT-7676 tag fixed-in-k2
There is one of checks left unimplemented (FirParcelizePropertyChecker.checkParcelableClassProperty)
because it requires huge commonization of detecting which type can be
serialized and which not, which is not prioritized job for now
Those modules are:
- :compiler:fir:providers, which contains Fir and Symbol providers,
scopes, and different utilities used by them
- :compiler:fir:semantics, which contains different abstractions and
entities which are used in resolution and in checkers
- :compiler:fir:resolve, which contains all stuff related to resolution
and inference
There are two pros of this change:
1. It may increase gradle build, because it allows to compile :fir:resolve
and :fir:checkers modules in parallel
2. Logic of working FIR (scopes, providers, DFA logic system, etc) is
now separated from logic of resolution phases, so for example checkers,
which are depend on scopes physically will not be able to run resolve
in any way
Dmitriy Novozhilov