Ensure that in IdSignatureBuilder hashId/hashIdAcc is only set
together with the description.
In 6142d75bb4 we implemented setting
descriptions when building signatures from descriptors, but forgot to
do the same for building signatures from IR, resulting in missing
descriptions in klibs.
See also: KT-59486
Also enables the integration tests for custom allocator and the
currently available GCs.
Co-authored-by: Troels Bjerre Lund <troels@google.com>
Merge-request: KT-MR-11199
Merged-by: Alexander Shabalin <Alexander.Shabalin@jetbrains.com>
Other type substitutors (classic, cone-based) respect the type
annotations and copy them to the resulting type for all
cases, including type parameters.
Without this change we cannot correctly match expect/actuals
when we replace actual type parameters with expect ones in case
the actual type parameter has type enhancement annotations
(e.g., `@FlexibleNullability`).
We transfer all annotations (and not conservatively copy only type
enhancement annotations), as 1) other substitutors do that 2) other
IR type substitution utilities (e.g., `IrType.substitute`) do that.
As we will attempt reimplementing all IR type substitution utilities
via IrTypeSubstitutor, it also makes sense to completely align
the behavior.
to satisfy MPP annotation checker.
It has reporting because @InlineOnly is absent on declarations with
Long parameter (removed in 233376eef0).
^KT-58551
Many errors are reported in stdlib with these annotations
(SinceKotlin, Deprecated, so on).
But having them only on expect is a valid case. E.g. SinceKotlin added
if some old platform-specific API becomes commonized.
^KT-58551
This implementation only checks annotations set on expect/actual
declarations and requires further refinement (e.g. checking of other
annotation targets, class scopes within typealiases).
^KT-58551
This will be needed in subsequent commits because context must be
accessible from `:fir:checkers` module, but it is in `:fir:resolve`
Intermediate interface `FirExpectActualMatchingContext` is needed
because `FirExpectActualResolver` relies on some FIR-specific methods,
and providing common `ExpectActualMatchingContext` interface is not
enough.
Also in `FirExpectActualMatcherTransformer` context extracted to field
to not create context for each processed element. "session" made
final to calm down warning "accessing non-final property in
constructor".
^KT-58551
3f3f6eb marks all cinterop-generated declarations with
@ExperimentalForeignApi. As a result, all usages of such declarations
have to opt-in explicitly. This commit adds those opt-ins to all
usages in the performance tests.
^KT-58362
If forward declaration exists in a library, it was
possible to import it both by forward declaration name
and normal library name. This is strange unique behavior.
And it would also make KT-59643 changes binary incompatible.
So from now it's only possible to import forward declaration by
forward declaration name only.
^KT-59642
cinterop tool should add ExperimentalForeignApi to all generated
declarations, to indicate their experimental status and discourage using
them in public Kotlin API. But the same considerations are applicable
to forward declarations (cnames.*, objcnames.*), which are generated not
by cinterop tool, but directly by the compiler.
This commit adds ExperimentalForeignApi to those compiler-generated
classes.
^KT-58362
cinterop tool should add ExperimentalForeignApi to all generated
declarations, to indicate their experimental status and discourage using
them in public Kotlin API. But the same considerations are applicable
to forward declarations (cnames.*, objcnames.*), which are generated not
by cinterop tool, but directly by the compiler.
This commit adds ExperimentalForeignApi to those compiler-generated
classes.
^KT-58362
`headers.x86-64` property in a cinterop .def file is not actually used
by cinterop. `headers.x64` should be used instead.
This commit removes it completely instead of renaming -- no functional
changes are done.
This commit introduces API for AtomicIntArray, AtomicLongArray and AtomicArray<T>.
The current set of functions is implemented via atomic arrays intrinsics (see KT-58360) and provides sequentially consistent memory ordering guarantees and no spurious failures in compareAndSet/compareAndExchange operations.
For details see: KT-60608
Merge-request: KT-MR-11071
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
These tests were initially testing that $EntriesMappings classes were
correctly generated, but started to check something else once the
language feature EnumEntries was enabled by default.
Sergej Jaskiewicz