Most of these tests used this directive as a way to opt in to a new
language feature, and most of those features are already stable for a
long time, so no opt-in is needed. Some other tests used the directive
to opt out from a language feature, replace those by the `LANGUAGE`
directive. One test used the directive to test behavior that actually
depended on the API version; use `API_VERSION` directive there instead.
Previously, for a property named `x` in the companion object of a class
named `Foo`, we generated:
- `Foo.access$getX$cp`, consisting of `GETFIELD Foo.x` and lateinit
assertion
- `Foo.Companion.getX`, consisting of `INVOKEVIRTUAL Foo.access$getX$cp`
Now, we generate:
- `Foo.access$getX$cp`, consisting of `GETFIELD Foo.x`
- `Foo.Companion.getX`, consisting of `INVOKEVIRTUAL Foo.access$getX$cp`
and lateinit assertion
The reason is that this way we can avoid generating another accessor and
reuse `Foo.access$getX$cp` in case `isInitialized` is called on a
lateinit property from companion.
For private properties, getX is not generated, but instead the assertion
is generated on each access to the field (which can be improved, see
KT-28331). The same happens for access to non-private properties from
inside the same context where they're declared.
#KT-21862 In Progress
Sometimes, state-machine, generated in inline functions with
crossinline parameter, is transformed, since all usages should be
renamed.
However, this is wrong: in this case, we will have state-machine
inside state-machine.
This fix addresses the issue.
#KT-25893 Fixed
* 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) { ... }
This looked like a small and useful change, but caused so many issues
(KT-24474, KT-24790, 30b9caea, and another unreported one -- see the
test update in this commit) that it didn't pay off after all. The
optimization is not that critical for now, as it's only relevant for
data classes where component types have trivial equals/hashCode
implementation, which is not very often
#KT-12330 Declined
Unlike ordinary lambdas, suspend lambdas do the computation in
doResume(Ljava/lang/Object;Ljava/lang/Throwable;)Ljava/lang/Object;
method. As you can see, there are no decomposed parameters. As a result,
they used not to be generated.
To fix the issue, I add decomposed parameters to value parameters while
generating local variables table.
In addition, when generating suspend lambda for inline, the codegen
does not take this kind of parameters into account. This is also fixed.
#KT-18576: Fixed
Kotlinc source’s file DescriptorUtils.kt demonstarted non-deterministic
insertion of checkExpressionValueIsNotNull for value returned by
CallableDescriptor::getOriginal(). It was difficult to reproduce
this behavior on ф smaller example, but I added a test which was
failing once in 5-10 times while I was testing manually.
I believe this bug is close to KT-23704.
This PR addresses non-determinism to a degree when I can run 120
Compilations with './gradlew dist' and get same classes in all
jars in 'dist'.
NOTE that thew fact that insertion of checkExpressionValueIsNotNull may
depend on order of the types seems suspicios. This CL only addresses
non-determinism part, but I believe it’s worth looking into this more
from semantics point of view.
Introduce COMMON_COROUTINES_TEST directive.
Every test with this directive is run twice: one time with
language version 1.2 and kotlin.coroutines.experimental package
and the other time with language version 1.3 and kotlin.coroutines
package. Each run is a separate method: with suffixes _1_2 and _1_3
respectively.
However, since codegen of release coroutines is not supported in JS
backend, we generate only one method: with suffix _1_2.
#KT-23362
- Do not longer call hashCode on java/lang/Object but do this
on statically checked type.
- Do not longer call Intrinsics.areEqual but use directly
equals method on statically checked type.
Fix of https://youtrack.jetbrains.com/issue/KT-12330
Alexander Udalov