* The members of Result are isSuccess, isFailure, exceptionOrNull, getOrNull
* The rest of API is implemented via inline-only extensions
* There are two internal functions to hide detailed mechanics of an internal
Result.Failure class: createFailure and throwOnFailure
* Result.toString is explicit: either Success(v) or Failure(x)
See KT-26538
<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.
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) { ... }
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
There were two problems:
- For asm type `OBJECT_TYPE` was used, which can be wrong in case of
inline classes, because it can be an underlying value of some inline class
- For KotlinType, type from rhs was used
Dmitry Petrov