* @ExperimentalForeignApi for all declarations that operate on
unmanaged memory (i.e. pointers and references)
* @BetaInteropApi for the rest of the interoperability declarations,
namely Swift/CInterop-specific interfaces and convenience-functions
### Implementation details
* Some typealiases are not marked explicitly because it crashes the compiler,
yet their experimentality is properly propagated
* License header is adjusted where it previously had been existing
* Deprecated with ERROR interop declarations that are deprecated for more than
two years are removed
* WASM target interop declarations are deprecated
* Deliberately make Boolean.toByte and Byte.toBoolean foreign-experimental to scare
people away
^KT-57728 fixed
Merge-request: KT-MR-9788
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
Current inline classes API is not compatible between different backends.
So implementing common function required for this optimization
was not possible in Native backend.
So, common default arguments lowering was refactored to make bigger
piece of code replaceable in backends.
^KT-57860
since we generate the default getter in this case in
Fir2IrDeclarationStorage.createIrProperty, so the serialized metadata
should follow the same behavior.
#KT-57373 fixed
`AtomicInt`, `AtomicLong`, `AtomicReference` and `AtomicNativePtr` classes were moved to `kotlin.concurrent` package. The corresponding classes from `kotlin.native.concurrent` were deprecated with warning since Kotlin 1.9.
In order to prepare for further commonization of Atomics API the following changes were made:
* `kotlin.concurrent.AtomicInt`:
* `increment(): Unit` and `decrement(): Unit` methods were deprecated with error
* New methods were added: `incrementAndGet(): Int` , `decrementAndGet(): Int`, `getAndIncrement(): Int`, `getAndDecrement(): Int`, `getAndSet(newValue: Int): Int`
* `kotlin.concurrent.AtomicLong`:
* `increment(): Unit` and `decrement(): Unit` methods were deprecated with error
* New methods were added: `incrementAndGet(): Long`, `decrementAndGet(): Long`, `getAndIncrement(): Long`, `getAndDecrement(): Long`, `getAndSet(newValue: Long): Long`
* Deprecated `AtomicLong()` constructor with default parameter value
* For all atomic classes `compareAndSwap` method was renamed to `compareAndExchange`
See KT-58074 for more details.
Merge-request: KT-MR-9272
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
Several interop tests fail with error:
"type kotlin.String? is not supported here: doesn't correspond to any C type"
Merge-request: KT-MR-9690
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
* Explain what obsolete means and why workers are obsolete
* Add some documentation to workers to explain its common pitfalls
^KT-54702
Merge-request: KT-MR-9563
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
Previously object count was tracked via allocator. It adds additional
burden on every allocation. Tracking via sweeper is better because
it mostly happens on the GC thread during a concurrent sweep.
On some platforms, `NSUInteger` is 32-bit, while the objc_direct tests
expected it to be represented as `ULong`. So the tests failed on those
platforms.
Fix the tests by replacing `NSUInteger` with `uint64_t`.
These tests were replaced by the 842a66c3 and now located
in :native:native.tests project
Merge-request: KT-MR-9256
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
with dedicated opt-in language feature and special
annotation or module capability.
Not intended for a general use, solves specific K/N
scenario with interop libs.
#KT-55902 fixed
Those classes mainly include KotlinCoreEnvironment and its dependencies
This change is needed for two reasons:
1. Splitting of some common configuration of compiler from logic of CLI
makes code structure more clean
2. There is a need to add dependency on `:analysis:analysis-api-standalone`
to `:compiler:cli`, because FIR analogue of AnalysysHandlerExtension uses
services from it. But the problems is that standalone AA itself depends
on classes for compiler configuration, which leads to circular
dependency between those modules. Extracting configuration to
`:compiler:cli-base` solves the problem
Vsevolod Tolstopyatov