This commit prevents language version increase due to bootstrapping
problems. Compiler version X attempts to build the project with the
current version X+1 -> warning about progressive mode cannot be enabled ->
error due to -Werror -> build failure.
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
They were needed as a temporary migration in scope of KT-58587
Now the bootstrap and IDE include KT-58587 patch, so @Suppress and
`final` are no longer needed
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.
the script declarations are considered public, at least because they
can be reused from another script then used with the `importedScripts`
configuration property. It also improves the compatibility with K1
scripting.
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.
UNNECESSARY_SAFE_CALL is a warning,
UNEXPECTED_SAFE_CALL is an error, thus
it's a breaking change.
Also see KT-60695.
^KT-59860 Fixed
Merge-request: KT-MR-11210
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
This change is necessary in order to make `FirElement` abstract class. To do it we need to remove all `accept` and `transform` methods from fir interfaces. So we have to make sure that all fir element implementations have their `accept` and `transform` implementations in their super classes. In particular this change makes 'accept' and 'transform' methods in `FirConstructedClassTypeParameterRef` and `FirConstructedClassTypeParameterRef` base classes.
This change is necessary in order to make `FirElement` abstract class. To do it we need to remove all `accept` and `transform` methods from fir interfaces. So we have to make sure that all fir element implementations have their `accept` and `transform` implementations in their super classes. In particular this change makes `FirImport` abstract class in order to preserve `accept` and `transform` methods after removing them from fir interfaces.
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.
Mikhail Glukhikh