With this change a new `-Xmetadata-klib` CLI flag becomes the
preferable way to instruct K2MetadataCompiler to produce metadata
KLIBs. The old `-Xexpect-actual-linker` flag still works for
K2MetadataCompiler, but that would last just for a short transition
period until the necessary changes are made in the Gradle plugin.
The K2NativeCompiler does not work anymore with `-Xexpect-actual-linker`
and respects only the `-Xmetadata-klib` flag. This is not an
issue since the Gradle plugin anyway supplies both flags for Native
metadata compilations.
^KT-61136
This is a precondition for obsoleting and finally removing
`-Xexpect-actual-linker` CLI key, which became useless since
the removal of ExpectActualTable.
^KT-61136
^KT-57858 Fixed
Remove FirEmptyOverridesBackwardCompatibilityHelper since it's not used anymore
Remove overridesMemberWithPlatformDependent.kt test file since it becomes redundant
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
In-block modifications are applicable only for FIR declarations with
fully resolved bodies. It can happen only during implicit type and body
phases. The implicit type phase probably is not applicable for our
particular case, but we will play safe because properties have a
complicated resolution logic, so it is hard to be sure that only body
phase will be enough.
Changes inside contracts are treated as out-of-block, so we can avoid
marker from this phase. Also, all mentioned calls inside bodies resolve
the corresponding declarations to the contract phase, so we will save a
lot with this optimization.
Q: Why in-block modification can be heavy?
A: In most cases this invalidation is pretty cheap because we have all
required information inside caches. But it is possible that we can
receive an in-block modification event for PSI without a corresponding
FIR element, or it is not yet fully resolved. In this case, for example,
we will do such redundant works as a raw FIR building or KtModule search
^KT-61842 Fixed
Buildscripts that used `ios`-shortcut certainly used
`val iosMain by getting` as well, which will lead to Gradle exception
after migration. Mention in the diagnostic message that one should
replace `by getting` with static accessors
^KT-60734
Dmitriy Novozhilov