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) { ... }
Fix for test data (inlineFunctionInsideInlineClassesBox.kt) is needed
to avoid check about "no inline functions".
This check has two steps: first, names of inline functions from
the metadata are loaded, then these names are checked that they are
presented for physical methods in the classfile.
Because now there are no physical methods in the classfile, we can't pass
the second check, therefore this fix is needed.
#KT-24872 Fixed
The changes are necessary because of release coroutines support:
- Get rid of suspendCoroutineOrReturn calls. It's anyway irrelevant
to what is being tested here
- In varValueConflictsWithTable.kt, variables slots have been shifted
because the variable for continuation's exception was removed
- In varValueConflictsWithTableSameSort.kt, a variable has been introduced
to preserve the same slot numbers for old variables.
Otherwise, they become shifted and to the second slot,
and there are a lot of irrelevant "ALOAD 2" instructions
This change is another example of why bytecode text tests are evil
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
Previously, assert was just a regular function and its argument used to
be computed on each call (even if assertions are disabled on JVM).
This change adds support for 3 new behaviours of assert:
* always-enable (independently from -ea on JVM)
* always-disable (independently from -ea JVM)
* runtime/jvm (compile the calls like javac generates assert-operator)
* legacy (leave current eager semantics) - this already existed
Default behaviour is legacy for now.
The behavior is changed based on -Xassertions flag.
#KT-7540: Fixed
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
NB we use 'Intrinsics.areEqual(Double, Double)' and
'Intrinsics.areEqual(Float, Float)', because right now we take
nullability from the inferred type of the expression (which is 'Any?' in
the test cases).
We should probably reconsider this in case of more exact information
available from the data flow analysis, e.g., in case of
fun test(x: Any?) =
x is Serializable && x is Double? && x == 0.0
We statically know that 'x' is not null in 'x == 0.0' (although it's
neither nullability of it's numeric type 'Double?' nor the nullability
of the inferred type 'Any?').
There might be some edge effects in the performance related to byte code
size and preventive unboxing and so on.
