Additionally, deprecate -Xgc in favour of a new binary option "gc".
This will allow setting gc right in gradle.properties
Merge-request: KT-MR-10498
Merged-by: Alexander Shabalin <Alexander.Shabalin@jetbrains.com>
For a Kotlin wrapper of an Objective-C object, this functions zeroes
and releases the strong reference from the Kotlin wrapper to the
Objective-C object.
Usually, such a release happens only when the Kotlin wrapper is GCed.
So using this function can help that happen sooner.
^KT-59134
Before this change `./gradlew help` (with native enabled)
Created immediately: 1322
Created during configuration: 1541
after this change:
Created immediately: 596
Created during configuration: 1509
To know more about configuration avoidance: https://docs.gradle.org/current/userguide/task_configuration_avoidance.html
Do not export extensions of classes that are
hidden from the generated Objective-C API.
Merge-request: KT-MR-10330
Merged-by: Sergey Bogolepov <sergey.bogolepov@jetbrains.com>
Normally during metadata compilation we use
`K2MetadataCompiler` and it serializes
metadata to klibs without generating IR.
Native shared compilation uses the K2Native
compiler, which generates klibs based on both
the fir and fir2ir information.
It would be nice to reuse `K2MetadataCompiler`
for native shared, but currently it has no
support for the commonizer, and also reads
the stdlib metadata from a jar instead of a
klib, and there's no simple idiomatic way
to pass the `distribution.klib` value down
to `KLibResolverHelper` (native compilation
has some commonized dependencies, and they
explicitly depend on `stdlib`, so we must
resolve it this way or strip it away to be
able to use the metadata jar instead). There
may be other issues, I only digged a bit.
Instead, this change modifies the K2Native
in such a way that it can generate klibs
with metadata without fir2ir info.
Note that this change does not fix KT-58139,
because KT-58139 fails due to performing the
constants evaluation directly during the
metadata serialization when the needed info
does (and, as I was told, should) not exist
(namely, valid property initializers).
^KT-58444 Fixed
Add more opt-ins in Samples, tests and Benchmarks.
This is a follow-up to KT-MR-9788
Merge-request: KT-MR-9997
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
The fix deals with the situation where a virtual function potentially from
the external world (because of the receiver) returns a final type (if it isn't final,
then it's conservatively assumed that no devirtualization could be done on it).
#KT-57791 Fixed
Dmitriy Novozhilov