There are multiple ways to declare a named variable-like entity in
Kotlin:
1. val/var variable declaration
2. destructuring declaration
3. parameter of a function
4. parameter of a lambda
5. destructured lambda parameter
6. for-loop's variable declaration
7. catch block exception declaration
8. val in when
9. field declaration
Out of them, only variable and field can be assignable, in other words,
they can be on the left hand side of an assignment.
Val/var variable declarations were already supported.
So, we needed to just support field initialization and tell the backend
that other ways are prohibited. Function and lambda parameters were
already been supported. So, the only thing to explain to the backend are
remaining ways.
#KT-39113 Fixed
#KT-34048 Fixed
For the same reason as in the previous commit: descriptors are cached
via weak references in moduleByClassLoader.kt and can be
garbage-collected at any point. So different instances of KParameterImpl
representing the same parameter may store different instances of
descriptors.
Descriptors are cached via weak references in moduleByClassLoader.kt and
can be garbage-collected at any point. So relying on identity of
descriptors in KTypeParameterImpl is dangerous because the same type
parameter can be represented by different descriptors. For example, the
test equalsOnFunctionParameters.kt was flaky before this change because
of this issue, and that could be reproduced by running it a few hundred
times in the same process.
Instead, use the type parameter's container (which is either KClass or
KCallable) and name, in equals/hashCode. KClass and KCallable already
have equals/hashCode independent of descriptors, so this works in case
the descriptor is invalidated.
- Allow participating subtypes of functional types in conversions
- Fix several subtle inconsistencies
- Place logic about conversions at one place
Now conversions operations have two stages: before usual subtyping
check and after one. This is needed to support conversions of
subtypes (of functional types, for example). First, the compiler
checks if it possible to resolve an argument without conversion and
only then it tries to perform conversion.
Note that it'd be incorrect to perform conversion eagerly as it can
change resolve (Runnable & () -> Unit <: KRunnable), plus we can't
guess whether conversion is needed at all as it's important not to
look into supertypes if resolution doesn't actually needed it
#KT-36448 Fixed
#KT-37574 Fixed
#KT-38604 Fixed
When we generate call for 'foo', we make decision about invoking
a 'foo$default' too late, after the call arguments are generated.
If 'foo' was an override, and base class (interface) was generic,
'foo' in base class could have a different Kotlin and JVM
signature, so the arguments we generated could be generated wrong
(primitive or inline class values instead of boxes, see KT-38680).
Also, we always selected first base class in supertypes list,
which caused KT-15971.
Look into resolved call and see if we should actually call
'foo$default' instead of 'foo' when determining actual callable.
Overrides can't introduce default parameter values, and
override-equivalent inherited methods with default parameters
is an error in a child class. Thus, if we are calling a class
member function with a default parameters, there should be one
and only one overridden function that has default parameter values
and overrides nothing.
Attributes are used to name continuation classes and are generated
before inline classes processing. During the processing, for override
functions in inlined classes, the compiler generates
STATIC_INLINE_CLASS_REPLACEMENT function with body of the override.
The override's body is replaced with delegating call to
STATIC_INLINE_CLASS_REPLACEMENT. However, since we need to keep the name
of the continuation class, we copy attributes from the override to
STATIC_INLINE_CLASS_REPLACEMENT. This leads to attribute clash during
AddContinuationLowering.
So, to fix the issue, do not use the attribute of
STATIC_INLINE_CLASS_REPLACEMENT in original->suspend map.
As an optimization, do not generate continuation for the override
function.
Since LocalDeclarationsLowering is a BodyLoweringPass, local
functions inside one declaration are handled independently of local
functions in the other declaration. This can lead to name clashes, in
case a local function with the same name and signature is declared in
overloads in the same container, which results in a signature clash
error in JVM IR.
The issue became more common with the introduction of adapted function
references, where psi2ir generates a local adapter-function with a
predefined name, which can easily clash with another reference to the
same target in an overload. This led to a compilation error when
bootstrapping Kotlin with JVM IR, for example in GradleIRBuilder.kt
where there are a lot of references to the same function.
The reason for this is that this flag is used right now in 'cli-common'
to workaround the problem that this module is compiled with API version
1.4, but runs with stdlib of version 1.3 (bundled to Gradle). The same
problem would appear with adapted function references, since we use
kotlin/jvm/internal/AdaptedFunctionReference in the bytecode, only
available since 1.4.
The fix is to generate adapted references in this case as subclasses of
the already existing kotlin/jvm/internal/FunctionReference. This can
change behavior in some extreme corner cases (because such references
can now be observed to have reflection capabilities), but it's an -X
argument anyway.
Another option would be to introduce another compiler argument
specifically for this, but it looks like it would only complicate things
without much benefit.
This fixes the problem in JVM IR backend which didn't pass bound
receiver value of an adapted function reference to the superclass
(kotlin/jvm/internal/AdaptedFunctionReference), which caused equals to
work incorrectly on such references (see changes in box tests).
Previously, bound adapted function reference was represented as
IrFunctionExpression to an adapter function which calls the callee. The
value of the bound receiver in that case could only be found in the body
of that adapter function. This is not very convenient, so this change
makes psi2ir produce a block of the adapter function + reference to it.
The bound receiver value is then found in the reference. This is
basically similar to what ProvisionalFunctionExpressionLowering is doing
for all function expressions. And since this IR structure is already
supported in FunctionReferenceLowering, the problem in the JVM IR is
fixed without any additional modifications.
However, inliners do not support this IR structure yet, see KT-38535 and
KT-38536.
since they are broken on JDK 11: they change Field.modifiers, which is prohibited
since JDK 9, because this private field is not exported.
Thus, we need to split the test into two: one with assertions enabled and the other
one with them disabled. Also, we need to run them in separate processes, for them
not to interfere each other.
#KT-27176 Fixed
Ilmir Usmanov