By ignoring type parameters. Since type parameters in annotations are a
very limited feature, their sole use is to be able to specify them as
KClass argument: annotation class Foo<T: Any>(val bar: KClass<T>).
Since we can encounter type param only as a KClass type argument (and
never as a property type), simple approach of ignoring them works fine.
In that case, since we simply copy property types to synthetic
implementation class, its properties in IR start look like this:
annotation class FooImpl(override val bar: KClass<T of Foo>). This IR
seems to be not completely correct, since FooImpl.bar type contains T of
Foo param, which is out of its scope. However, so far I didn't
encounter any problems with this during testing and after MR discussion
this approach has been considered possible.
#KT-59558 Fixed
#KT-59036 Fixed
Refactoring in 4986cb14 introduced an unintentional behavior change:
private symbols are now findable in symbol table with lookup by
signature.
Unfortunately, this is not correct - private symbol signature might not
be unique (or at least was sometimes not unique in older compiler
versions), which leads to crashes on deserializing corresponding klib.
This commit restores old behavior.
^KT-60616
Temporary solution for K1 - see comments in the code
it seems that a scenario reproduced in the MainKtsTest.testKt48812
wasn't covered with analogous changes before.
And it wasn't detected while main-kts tests weren't a part of the
K1 scripting tests.
The test is fixed now, and testing of main-kts is restored.
and base class handling:
Since in K2 we do not distinguish between script arguments taken from
the base class and provided properties, we need this extra functionality
to preserve the argument order of K1 scripts.
This is a temporary measure, since we're going to deprecate base class
usage at some point (KT-60449), so the relevant constructor arguments
should disappear too.
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
`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
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
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.
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
The following updates in the JVM/IR plugin were made:
* Lots of refactoring with preparation for K/N support: commonization of transformations.
* Improved error handling (checks for visibility constraints, appending message about usage constraints in case of an error).
* Explicit requirements for the visibility of atomic properties: to prevent leaking they should be private/internal or be members of private/internal classes.
* Fixed visibility of generated properties: volatile properties are always private and atomic updaters have the same visibility as the original atomic property.
* Volatile fields are generated from scratch and original atomic properties are removed.
* Delegated properties support is fixed (only declaration in the same scope is allowed).
* Non-inline atomic extensions are forbidden.
* For top-level atomics: only one wrapper class per file (with corresponding visibility) is generated.
* Bug fixes.
The corresponding tickets:
https://github.com/Kotlin/kotlinx-atomicfu/issues/322
KT-60528
Merge-request: KT-MR-10579
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
In early prototypes of interpreter, it was easier to assume that
all classes from Java can be interpreted and fix something if not.
Check for Java declaration was done by checking that the package name is
starting with "java". But this is actually wrong and can lead to errors
when some code is declared in "java" something package, but is not from
Java stdlib.
#KT-60467 Fixed
Leonid Startsev