Note that LazyClassMemberScope actually has a separate field for
KotlinTypeRefiner, and it might be actually different from the one in
c.kotlinTypeChecker.
The one in c.kotlinTypeChecker is the refiner of *owner* module, i.e. a
module in which the class has been declared. If we have a class Foo :
Expect in common, then the refiner will be from common, and thus it
won't be able to refine supertypes to their platform-dependent values.
The one passed in constructor is actual refiner of dependant-module.
Say, if we're looking at Foo from the point of view of jvmMain, then
we'll create a (view-dependent) LCMS for that, and it will contain
refiner for jvmMain.
It is important to use proper refiner, otherwise the idea of having
"module-dependent view" breaks, and we might suddenly mismatch some
overrides with expect-classes in their signatures.
^KT-44898 Fixed
If there's a frontend error in a test, or bytecode generation crashed
with an exception, it makes no sense to run JVM test handlers such as
lambda inlining checker or D8 checker.
This removes another dependency of 'ir.tree' on 'frontend', and among
other things, makes it possible to implement TranslationPluginContext
for FIR in the future.
Extract a service interface out of ControlFlowInformationProviderImpl
and register its implementation in two "leaf" modules: 'cli',
'idea-core'.
This improves parallel build, since a lot of modules depend on
'frontend' but only these two modules reference the implementation and
thus depend on the full CFA implementation now.
Do not use default parameter value for functions with only 1 or 2 call
sites, since it doesn't add much value but provides a dangerous
possibility to forget to pass the real implementation.
This is needed in order to have a single convenient place where to
register frontend services implemented _outside_ of the 'frontend'
module, such as the control flow analysis, extracted to a separate
module in a subsequent commit.
These utilties are used not only within CFG, but from the frontend and
idea as well. Therefore upon extraction of CFG into another module,
these two new files will remain in 'frontend'.