Currently, the test files are only analyzed as source code, and present
errors do not affect code fragment analysis. In the following commits,
however, the test files will be compiled to test code fragment
analysis against library sources.
One of the compiler lowerings, namely `PropertyReferenceLowering`,
optimizes usages of property references in some cases,
and if a containing delegated property accessor is inline,
it might need this accessor's bytecode.
If an accessor function is defined in a different module,
IDE tries to acquire its bytecode via the index, however,
the index doesn't cover classfiles from compiler output,
and that leads to errors like KTIJ-26706 and IDEA-320283.
One of the ways to ensure that the bytecode exists is to include files
that contain inline accessors in the compilation process. For example,
if file f1.kt from the analysis result contains property `val p by D()`,
and `D.getValue` is an inline function defined in file f2.kt,
then f2.kt must be present in the analysis result.
If f2.kt contains another property `val q by E()`,
and `E.getValue` is an inline function defined in f3.kt,
then f3.kt must be present in the analysis result. And so on.
Fixes KTIJ-26706, IDEA-320283
Merge-request: KT-MR-11793
Merged-by: Alexander Kuznetsov <Aleksander.Kuznetsov@jetbrains.com>
The only case when erasure matters in a context of materialization of
`PromisedValue` is when the type is a type parameter which upper bound
is an inline class. Since `PromisedValue::materializeAt` is a hot spot
and `eraseTypeParameters` is an expensive operation, we should not do
type erasure in other cases.
Collecting 'moduleInfo' is required for the old history-file-based
incremental compilation approach. And the way how it is being collected
violates Gradle project-isolation feature as it accesses all Kotlin
compile tasks from other Gradle subprojects.
When the new IC based on classpath snapshot is enabled, the plugin will
not collect 'moduleInfo' making it compatible with project isolation.
^KT-59826 Fixed
4774912f updated the patterns for the filecheck_constants_merge test,
because the commit slightly changed the code generated for TypeInfo.
But the test update was made with a copy-paste-related mistake.
As a result, the test didn't work with `-Ptest_with_cache_kind=static`.
This commit fixes this, buy reverting the unintended changes in
the filecheck patterns.
The header klib is supposed to only contain the public abi of the module
similar to jvm-abi-gen. It is intended to be used as a dependency for other
klib compilations instead of the full klib for compilation avoidance.
^KT-60807
This diagnostic checks if the Build Tools API implementation version is consistent with KGP in the case compilation goes using the old way
#KT-61449 Fixed
Yan Zhulanow