In IR interpreter we have "preprocessors". Preprocessor is a
transformer that changes IR expressions in a way that we can
interpret them at least partially.
We have two places where interpretation is happening:
1. Right after fir2ir where we evaluate only strictly necessary
expression for `const val` and annotations.
2. In lowering for every backend where we are doing some
constant folding.
Earlier, to avoid double work, we didn't launch preprocessors
in backend if we were using K2. But this approach breaks compilation
for MPP projects where one module is compiled with K1 into klib
and the overall project is compiled with K2. On the backend side,
we are mistakenly assuming that preprocessors were launched, but they
were not.
The solution is to run preprocessors only on the backend side. If we
think about it, interpretation on fir2ir doesn't require any
preprocessing because we are working only with expressions that are
correct and must be fully evaluated.
#KT-62126 Fixed
When files from different IrModules are merged in IrActualizer
their IrModule link was not updated. This led to assuming them
as different modules, and incorrect internal visibility handling.
^KT-62623
Ideally, instead of this method, there should be a link
to IrModuleFragment. Unfortunately, it would require to big refactoring,
as some of IrPackageFragment implementations doesn't have any
IrModuleFragment inside, and are not located inside any
IrModuleFragment.
So for now, we just implement and use everywhere a single way of
getting the module descriptor, which respects a IrModuleFragment
link if it exists, and fallbacks to descriptor-based method
if it doesn't.
^KT-62623
K1 reports `ARGUMENT_TYPE_MISMATCH`
and `TOO_MANY_ARGUMENTS` together, and
one way to do it in K2 is to say that
their kinds of inapplicability difference
is not relevant to the user.
Note that K1 doesn't do such filtering,
so this change "makes K2 closer to K1",
but still different.
^KT-62541 Fixed
fixup! [FIR] Show ARGUMENTS_MAPPING_ERROR diagnostics along with INAPPLICABLE
...in `ACTUAL_ANNOTATIONS_NOT_MATCH_EXPECT` diagnostic message.
Unlike in previous commit, this can't be fixed right in
`FirSymbolRenderer`, because `ConeIdRendererForDebugging` renders
differently and a lot of lazy resolve tests rely on that.
^KT-62585
It shouldn't break existing usages, because
1) default `ConeIdRendererForDebugging` renders ClassId in
same way as before the change;
2) I didn't find any usages, which use non-default idRenderer,
but rely on full ClassId be rendered for qualifiers.
^KT-62585
The commit (7db2fc522e) with changing behavior of builtin symbol provider
is in a conflict with a commit (72de86a8ba) where new tests were added.
The difference should be fixed as a part of KT-62651
Currently, the performance overhead when loading a Gradle property
consists of:
1. Creating a Provider
2. Resolving the Provider
Both steps are performed even when the same property was loaded before.
That means this overhead will multiply when there are a large number of
property read requests (e.g., in KT-62496, the tested project 400,000
read requests for only 17 properties).
To improve performance, we will now cache both steps with a
BuildService.
With this commit, configuration time for the tested project returns to
the same level before commit d6becee where the performance regression
happened (that commit can't be reverted because it introduced
`Provider`s which are required for proper Gradle usage).
Test: Manually verified on the large project in KT-62496
^KT-62496 Fixed
There are two BUG_FIX features that have
been added to the compiler, without a clear
decision to enable them somewhere in the
future. Since there is no decision to
force users rewrite their code, such
features should not be enabled in
Progressive Mode.
^KT-62644 Fixed
^KT-62143 Fixed
Ivan Kylchik