It's difficult to fix KT-22818 until the IR comes along, so we're
providing a workaround where one can disable the
ACTUAL_FUNCTION_WITH_DEFAULT_ARGUMENTS error and provide default values
in the actual function, to avoid exception from the backend.
#KT-22818
When we've determined that we are going to invoke an erased inline class
method ('static foo-impl(this, ...)' in inline class), keep track of it
so that the remaining type mapping logic proceeds correctly.
#KT-26998 Fixed Target versions 1.3.20
When mapping callable method signature for erased inline class methods,
use original function descriptor instead of super declaration
(otherwise it would map to a default interface method with mismatching
signature).
When generating delegates to Kotlin default interface methods, keep
track of the original Kotlin types for delegating method arguments and
interface method arguments.
'original' for value parameters of fake overrides points to the
overridden function value parameters instead of the value parameter of
the unsubstituted function. This causes inconsistent type mapping for
inline classes implementing generic interfaces with default methods.
#KT-25295 Fixed Target versions 1.3.20
#KT-26931 Fixed Target versions 1.3.20
In MemberDeserializer.loadProperty, we incorrectly passed 0 to
getAnnotations when loading annotations on property accessors in case
the protobuf field getter_flags/setter_flags was not present. The
correct behavior, as described in metadata.proto, was to pass a special
"default accessor flags" value, constructed from the main property
flags. Otherwise in case there were annotations both on the property and
on the accessor (as in PropertyAndAccessor.kt) and the accessor was
otherwise default, we would assume that it had no annotations and would
not load them in compiler and reflection
#KT-25499 In Progress
<IMPL_SUFFIX> for method is a method signature hash,
if method value parameter types contain inline class types,
otherwise 'impl'.
Constructor methods are named as 'constructor-<IMPL_SUFFIX>'.
Synthesized 'box' and 'unbox' methods are named as
'<METHOD_NAME>-<IMPL_SUFFIX>'.
Erased implementations of overriding and non-overriding methods
are named as '<METHOD_NAME>-<IMPL_SUFFIX>'.
Fully specialized implementation of 'equals' will have a special suffix.
We might want to add 'init' blocks later, so now, for the sake of
binary compatibility with 1.3-RC binaries, we have to generate these
'constructor' calls.
Note that in some tests inline class boxing is no longer redundant,
because resulting value is passed to 'constructor' as an argument.
Suspend functions and callable references to suspend lambdas are already
supported.
Support callSuspendBy of suspend function of big arity.
#KT-24854: Fixed
Avoid name clashes in cases such as
inline class Login(val login: String)
inline class Password(val password: String)
fun validate(login: Login) { ... }
fun validate(password: Password) { ... }
This change would also make NotNull annotations to be generated on
non-primitive annotation methods, but we skip this deliberately because
annotation methods never return null on JVM anyway
#KT-25287 Fixed
Same as for primitives: inline lambda expects to see a boxed value,
so, even if an argument is a local variable, it can't be remapped,
because it contains unboxed representation.
Arguments are put on stack in the direct order, and then stored into
local variables for inlining in the reversed order:
<arg0>
<arg1>
<arg2>
store <param2>
store <param1>
store <param0>
Original value parameter types were taken in direct order, though.
When we have a nullable inline class value with non-null underlying
type, corresponding value in unboxed representation is nullable. E.g.:
inline class Str(val value: String)
fun test(s: Str?) = listOf(s)
Here 'test(s: Str?)' accepts nullable 'java.lang.String' as a parameter.
When boxing/unboxing nullable values of such inline classes, take care
of nulls.
#KT-26052 Fixed Target versions 1.3-M2
Alexander Udalov