While we have an overload resolution algorithm working for O(n^2),
call resolution for the single particular call may work more then just
a second.
Thus, we need to call ProgressManager.checkCanceled() with more granularity
^KT-35135 Fixed
See 62a55b7b00
Previously, it was working for O(n^2)
Now, we first group it by jvm descriptor,
then for each groups of size g_i finding the most specific for O(g_i^2)
It should help for the cases when we have a lot of overloads with
different JVM descriptors (modulo return type)
NB: Having the same JVM descriptors is rather rare, because
in Java one cannot generate such a class.
Looks like it's only possible for Scala or some other JVM languages (KT-17560)
It should help a lot for KT-35135
Bug fix `NoConstantValueAttributeForNonConstVals` removes constant attribute from non-constant properties.
Code using such properties does not have to be recompiled, since its value is no longer inlined.
Somehow, I missed, that its 'create' function has bit arity, while
'invoke' does not. Thus, instead of directly passing arguments of
'invoke' to 'create', pack them into an array first.
1. All functions marked with @Deprecated from Kotlin/Native platform libraries
have DeprecationLevel.ERROR, and therefore practically can not be used by
a developer in their code. So, it does not make sence to keep such
declarations in commonized libraries.
2. Commonization of such functions would also require commonization of
annotations with nested annotations as const values (ex:
@Deprecated(level = DeprecationLevel.ERROR), where both @Deprecated
and DeprecationLevel are annotation classes). This is not implemented yet.
This is necessary to reduce memory consumption in commonizer while
processing sets of massive libraries.
Ex: ios_x64 (127 libraries) vs ios_arm64 (127 libraries).
This commit partially reverts 970ee4539b.
The Kotlin/Native klib compilation task configuration logic involved
adding dependencies for the compiler plugin artifacts. However, the
compiler plugins classpath, shared across all of the K/N tasks, was
tracked as the tasks' input. This made the following scenario possible:
1. Configuration of some of the Kotlin/Native tasks is avoided at the
evaluation phase;
2. During task graph construction, one of the tasks are evaluated, and
to determine their dependencies, Gradle resolves their inputs,
including the compiler plugins classpath mentioned above;
3. Another K/N task is evaluated afterwards, and the configuration logic
attempts to add a dependency into the compiler plugin classpath
configuration, which has already been resolved in (2).
The build fails.
Fix this by cancelling task configuration avoidance for the K/N tasks.
Issue #KT-36804 Fixed
Ilya Kirillov