In the FIR generator, the `AbstractElement` class was used to
represent either an element type without type arguments applied
(using the `Element` subclass), or an element type with applied type
arguments (using the `ElementWithArguments` subclass).
Instead, it is more logical to use the `Element` class to always
represent a non-parameterized element type, and for a parameterized
element type use the `ElementRef` class, just like we do
in the IR generator.
Review: https://jetbrains.team/p/kt/reviews/12279/files
Motivation: make sure that cases like KT-62027 won't happen again
Review: https://jetbrains.team/p/kt/reviews/12279/files
Now it's responsibility of the
`createExpectActualTypeParameterSubstitutor` calller to think about the
case when parameters size isn't equal. You must not be able to create a
substitutor if type parameters sizes are not equal
Improvement in `createExpectActualTypeParameterSubstitutor` API also
improves
`AbstractExpectActualCompatibilityChecker.getCallablesCompatibility`
API.
Because suppose that you accidentally created a redundant wrapping
substitutor => you need to handle the case of not equal type parameters
size on the call site => you start thinking why you should do that on
the call site? It must be a responsibility of
`getCallablesCompatibility` => you realize that you created a redundant
wrapping substitutor
Extract the common logic of remapping fake overrides into a function.
Also, slightly change behavior of the check to be stricter: now it's
using `as S?` instead of `as? S`, which means that if the remapped
symbol is present in `fakeOverridesMap`, then it must be of the same
type.
...actualized via typealias. This caused false-positive report of
`ACTUAL_ANNOTATION_CONFLICTING_DEFAULT_ARGUMENT_VALUE`.
In such case it's incorrect to compare signatures, because classes have
different `ClassId`s. Instead, classes could be compared using
`areCompatibleExpectActualTypes` which actualizes both types, and
then enum value names compared.
^KT-62104
^KT-59940
It has been renamed to IdSignatureFactory. We have to keep
IdSignatureSerializer as a typealias for a while to keep the source
compatibility with the Compose compiler plugin.
Now there is separate class encapsulating logic about how to build
fakeOverrides and one encapsulating logic of which classes
do need building fake overrides.
This also allows to untie strange inheritance dependencies.
^KT-61934
Previously, it had some internal state that was saved between calls
and needed to be cleared.
This state was eliminated, which makes invariants clearer and using
easier.
^KT-61934
Implement an infrastructure for checking IR before JS klib serialization.
Implement the EXPORTING_JS_NAME_CLASH and EXPORTING_JS_NAME_CLASH_ES checks.
^KT-61710 Fixed
This is the first step to replace the usages of `Importable`
in the FIR generator with `TypeRef`.
This is a step towards commonizing the code generator between
FIR and IR: KT-61970
It's implemented as IR checker because in K2 constant expressions are
evaluated on backend. FIR diagnostic removed because isn't needed.
"annotationViaActualTypeAlias" test has no `// FIR_IDENTICAL` because
diagnostic reported on entire typealias declaration instead of its name.
This is because in IR+LightTree we have only offsets, so can't navigate
to typealias name element.
^KT-59940 Fixed
...to not write call of each checker inside IrActualizer.actualize.
This is needed because new IR checker will be addded in subsequent
commits.
^KT-59940
This is more consistent with the code of
the common compiler checkers.
It would be nice to refactor the contents
of this object further, but it's out
of scope of the current branch.
^KT-54596
Ivan Kylchik