These intrinsics are equivalent to KMutableProperty0.get/set invocation and used internally to optimize allocation of a property reference.
Merge-request: KT-MR-11233
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
Implementation is very similar to the `enumValues` intrinsic.
Java enums and old (pre-1.9) Kotlin enums will be supported in a
subsequent commit.
#KT-59710
Now the stub-based symbol provider is reused for common source sets,
which use metadata dependencies. Filtering should be done on scope
level, then declaration provider won't yield them in the first place.
KT-58769
Use existing stub-based JVM library symbol provider for .knm and
.kotlin_metadata files. The only real difference is the scope filtering
by file types
KT-58769
Note that `FlexibleNullability` doesn't
exist anymore: it was removed at
`65ea4e18`.
`preserveEnhancedNullability = true`
was needed because if we have an
`@EnhancedNullability DNN`, and we
substitute something into it, then
`withNullability` is called there becase
that's how DNNs work, not becase we want
to obtain some new type with a
different nullability.
This is backed by
the `compiler/testData/diagnostics/tests/j+k/integerNotNullable.kt` test
where we first have
`@EnhancedNullability T & Any`, then
we substitute `{T -> kotlin/Int!}` and
then inside
`org.jetbrains.kotlin.fir.resolve.substitution.AbstractConeSubstitutor#substituteOriginal`
(this is a DNN-specific function) we
call `withNullability(NOT_NULL)`,
and expect the attribute to be preserved. Otherwise this test would
fail with
`OVERLOAD_RESOLUTION_AMBIGUITY` for
`IntBox().put(1)`.
^KT-50221 Fixed
Merge-request: KT-MR-11272
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
`ManglerChecker` is a class that verifies that for each IR declaration
(except some, see its `needsChecking` property) its mangled name
(computed from IR) is the same as the mangled name computed from its
frontend representation — `DeclarationDescriptor` on K1 or
`FirDeclaration` on K2.
The way it does it is as follows.
On K1, `ManglerChecker` looks if the declaration has a true,
non-IR-based descriptor, it if it does, then it checks it
(see ManglerChecker.Companion#hasDescriptor).
On K2, since we don’t have any descriptors, `ManglerChecker` looks if
the declaration’s metadata property is `null` (because the corresponding
`FirDeclaration` is stored there). If it’s not, it checks it
(see ManglerChecker.Companion#hasMetadata).
The issue is that those two conditions are not equivalent.
When the Compose compiler plugin transforms an IR function, it copies
its `metadata` property (as it should, because `metadata` can contain
anything, not necessarily the frontend representation), but doesn't set
the descriptor. Because of that, on K1 that transformed function is
skipped in `ManglerChecker`, and on K2 it’s not.
The correct usage would be to properly distinguish which declarations
come from the FE as is, and which are transformed/synthesized,
and skip the latter. But it is unclear how to implement this.
For now, the easiest way to fix this on K2 is to not run ManglerChecker
at all.
KT-60648
^KT-59448 Fixed
Invocation of atomic intrinsics is only allowed on property references that are known at compile time. This commit makes it possible to also invoke intrinsics on a constant property reference getter passed as an argument.
See KT-58359
Co-authored-by: Pavel Kunyavskiy <Pavel.Kunyavskiy@jetbrains.com>
Merge-request: KT-MR-10413
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
This way it is a little less "hacky". We are looking only for "data"
property, and as long as this property is declared in constructor, we
can safely assume we will get the correct one even if it is
renamed.
Drop excess call of `callStack.loadState(it)` when store state for
extension receiver. When we interpret lambda with extension receiver,
this receiver will be actually represented as a value parameter,
and it required some additional processing. Apparently, after all
interpreter's refactorings, this does not matter anymore and excess
call can be dropped.
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
Kirill Rakhman