For a vararg parameter type, there corresponding FIR element has a fake
source of kind ArrayTypeFromVarargParameter. As a result,
`getOrBuildFir` returns the whole `FirValueParameter` for the parameter
type reference. Therefore, we need some special handling for this case
in order to resolve the proper `KtSymbol`.
The main purpose is to show that old frontend and FIR work differently
in the case of the conflicts of local and top level classes/objects
See the tests that marked with // IGNORE_FIR
Corresponding ticket is ^KT-45192
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
Also changed FE1.0 checker and all related fix factories to report error
on the declaration instead of the lateinit modifier. This is consistent
with the direction of all checkers in FIR (no reporting on modifiers).
Logic of module dependencies is enhanced to filter out incompatible
common -> platform dependencies. However the reversed index for getting
all modules that use libraries doesn't take this filtering into
account and returns all modules based exclusively on order entries.
This leads to incorrect library dependency calculation.
^KT-44638 Verification pending
The idea behind this commit is that Move Refactoring should warn
developers in case their intention potentially breaks sealed
hierarchies (members must share the same module and package).
Provided algorithm has two goals:
- prevent destruction of correct hierarchies
- help in fixing broken ones
Pavel Kirpichenkov