fixup! Fix `isKotlinFunctionWithBigArity` function
Fix `isKotlinFunctionWithBigArity` function
Previous implementation could return false positive results, e.g. for
class named `abacaba.kotlin.Function42`
^KT-61548: Fixed
Merge-request: KT-MR-11928
Merged-by: Vladislav Grechko <Vladislav.Grechko@jetbrains.com>
Although 'VirtualFile's are typically inside the containing package
directory, e.g. 'foo/bar/Baz.class' for 'foo.bar.Baz', there might
be classes with files in unexpected places. Sources of such classes
may include broken stubs, or just classes from misbehaving IDE plugins.
As we are yet to identity such cases, here we treat them as 'other'
candidates.
In complex projects, there might be several library copies (with the
same or different versions). As there is no way to build a reliable
dependency graph between libraries, a project library depends on all
other libraries. As a result, there might be several declarations in the
classpath with the same name and signature.
Normally, K2 issues a 'resolution ambiguity' error on calls to such
libraries. It is acceptable for resolution, as resolution errors are
never shown in the library code. However, the backend, to which
'evaluate expression' needs to pass FIR afterwards, is not designed for
compiling ambiguous (and non-completed) calls.
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
Alexander Udalov