^KT-59665 Fixed
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
It's better to have this logic in common place
(AbstractExpectActualCompatibilityChecker) to avoid missing compilation
errors in the future
This commit fixes:
1. Missing compilation error for actual function with default arguments
for 'actual typealias' KT-59665
2. Missing compilation error for actual function with default arguments
for actual fake-override KT-59665
Alternative solution for KT-59665 is to create a special checker.
"incompatibility" vs "special checker":
Arguments for common incompatibility:
- What if we had a rule that expect and actual default params must
match? If so then it certainly would be an incompatibility.
- Technically, we do the matching of expect and actual params (because
we allow default params in common ancestors of expect and actual
declarations).
- It's hard to check that the actual definition doesn't use default
params because `ExpectedActualResolver.findActualForExpected` filters
out fake-overrides and doesn't return them. It's not clear logic for
me, that I'm afraid to touch.
implicitActualFakeOverride_AbstractMap.kt test breaks if you drop this
weird logic
- WEAK incompatibilities can be considered as "checkers". So it doesn't
matter how it's implemented, as a "incompatibility" or a "checker"
Arguments against common incompatibility:
- Although we match expect and actual declarations to allow default
params in common ancestors of expect and actual declarations, it's
still can be considered that we check that the actual declaration
doesn't have default params. And it doesn't feel right that we check
correctness of the actual declaration in expect-actual matcher.
- ~~It may change the rules of expect actual matching~~ (It's not true,
because ActualFunctionWithDefaultParameters is declared as WEAK
incompatibility)
This change covers the case where some f/o was generated in common module
and it is referenced in platform code. But signature of this f/o may be
different in different modules because of e.g. actualization of value
parameters with actual typealias
^KT-60850 Fixed
Consider the following example from
`extensionLambdasAndArrow.kt`:
```
val x4: String.() -> String = if (true) {
{ str: String -> "this" }
} else {
{ str: String -> "this" }
}
```
Because of
`coerceFirstParameterToExtensionReceiver`
the given lambdas must be of the type
`String.() -> String`, but because of a bug
they are `String.(String) -> String`. At the
same time, during inference their expected
types are, indeed, calculated correctly as
`String.() -> String`.
^KT-59394 Declined
(no more compiler crashes, #potential-feature)
For annotations defined in Java, IrProperties do not contain initializers in backing fields,
as annotation properties are represented as Java methods.
Therefore, it is not possible to use initializer values as default values for constructor parameters.
However, K2 stores default values in annotation's constructor parameters,
so it is possible to fix this issue if they're properly transfered to the IR
and inspected in JvmAnnotationImplementationTransformer
#KT-47702 Fixed
#KT-47702 tag fixed-in-k2
Unfortunately, there are still problems with running JVM backend tests
with JVM target 21 because:
1) The D8 version that we use does not support bytecode version 21, and
updating to a newer version requires to change JVM target of compiler
tests to 11. This will be addressed separately when we enable JVM 21
in tests-different-jdk.
2) Some tests are failing because of KT-60659 and KT-60770:
- builtinStubMethods/bridgesForStubs/emptyStringListAdd.kt
- jdk/stream.kt
- regressions/kt528.kt
#KT-60662 Fixed
Bytecode inliner boxes primitive types in class literals of reified type
arguments. This is by design, and we should backport this behaviour to
IR inliner.
^KT-60144: Fixed
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
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>
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>
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.
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
This lets us properly complete the call which fixes some issues with
false-positive type mismatches.
This change doesn't apply to array literals in annotation calls yet
because they are resolved as context-dependent.
This will be adapted in a following commit.
#KT-59581
This is basically a workaround for a slightly different IR generated by
fir2ir vs psi2ir. Simplified, psi2ir generates something like this for
the sample from KT-59218:
TRY type=Unit
try: BLOCK type=Unit
VAR methodHandle [...]
TYPE_OP type=Unit origin=IMPLICIT_COERCION_TO_UNIT
CALL invokeExact [...]
While fir2ir generates the following:
TYPE_OP type=Unit origin=IMPLICIT_COERCION_TO_UNIT
TRY type=Any?
try: BLOCK type=Any?
VAR methodHandle [...]
CALL invokeExact [...]
The lowering relies on the fact that a polymorphic call (`invokeExact`
in this case) is a direct argument to the TYPE_OP, to determine the
correct return type (Unit in this case) to be generated in the bytecode.
The solution here is to push the type coercion "through" all the
block-like structures (`try`, `when`, container expression) so that if
the last statement in the block is a polymorphic call, it gets properly
converted even if the whole block is under a type coercion operation, as
it happens in fir2ir. We achieve that by using the "data" parameter of
the IR transformer: appropriate immediate children of
IrTypeOperatorCall/IrTry/IrWhen/IrContainerExpression get the type that
the expression needs to be coerced to, and all the other expressions
ignore that type and set it to null when transforming their children.
A proper solution would be to ensure fir2ir generates exactly the same
IR as psi2ir (KT-59781), but since PolymorphicSignatureLowering is the
only lowering affected so far, and polymorphic calls occur very rarely,
it seems safe to workaround it in the lowering for now.
#KT-59218 Fixed
This is important for IR lowerings like PolymorphicSignatureLowering
which are very sensitive about the correct types of expressions and
placement of coercions to Unit (KT-59218).
A boolean parameter to `insertImplicitCasts` is not the best solution to
ensure that coercion to Unit is added. The best solution would be to fix
the TODO and generate coercion to the block's type for the last
statement. But that will affect many other places and will need to be
done separately => KT-59781.
Code in IrInterpreter is uncommented to fix the FIR test
`compiler/testData/ir/interpreter/exceptions/tryFinally.kt`; otherwise
evaluation of the function `returnTryFinally` there crashes with
"NoSuchElementException: ArrayDeque is empty". No idea why this test
didn't fail for K1 though, since the created IR is exactly the same.
For some unknown reason this breaks WASM backend with K2, but not with
K1 => KT-59800.
This aligns the behavior with K1 and fixes an issue when the default
value was deserialized as FirExpressionStub leading to an exception
in FIR2IR when trying to convert it to an IR expression.
#KT-60120 Fixed
#KT-59610 Fixed
Before this commit, we copied each type parameter during method
enhancement, while not copying the symbol. This led to symbol clashes
in MPP scenarios and various other problems.
Now we create a fully-functional type parameter copy in enhancement
and perform a substitution of old type parameters with new ones
in receiver type, value parameter types, return type,
and type parameter upper bounds.
#KT-59766 Fixed
#KT-59738 Fixed
Supported atomic update of elements for IntArray, LongArray and Array<T>
See KT-58360
Merge-request: KT-MR-11020
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
Ivan Kochurkin