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
It is not obvious from 'KotlinSingleTargetExtension' that calling
into 'target' is unsafe and it might throw.
Ordering code (especially with Android) is hard:
It is not clear when the target will become available.
The Future (and forAllTargets implementation) is intended
to make working with targets generically more safe.
KT-61634
Dmitriy Novozhilov