Supported:
- conversion in resolution parts. Also sam-with-receiver is supported automatically
- separate flag for kotlin function with java SAM as parameters
TODO:
- fix overload conflict error when function type is the same byte origin types is ordered
- consider case when parameter type is T, T <:> Runnable
- support vararg of Runnable
[NI] Turn off synthetic scope with SAM adapter functions if NI enabled
MPP-related:
* inherited from interfaces
* inherited body from interface
* default arguments in an interface, implemented by a class delegate
* super call of a method with default argument
Also:
* inheritance from an interface and another interface descendant (KT-21968)
* inheritance through an intermediate interface
This commits adds a new annotation OptionalExpectation to the standard
library, which is experimental. To enable its usage, either pass
'-Xuse-experimental=kotlin.ExperimentalMultiplatform' as a compiler
argument, or '-Xuse-experimental=kotlin.Experimental' and also annotate
each usage with `@UseExperimental(ExperimentalMultiplatform::class)`
#KT-18882 Fixed
'fun CharSequence.iterator()' is an extension function, so one can
overload it with custom implementation.
Other "predefined" containers such as arrays and ranges have member
'fun iterator()', so these containers are not affected.
Check that 'iterator' call corresponds to an extension function
'iterator' defined in package 'kotlin.text' with a receiver of type
'kotlin.CharSequence'.
#KT-24156 Fixed
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.
`countDefaultParameters` uses `hasDefaultValue` to compute the number of
parameters which have default values, which handles actual parameters
(who have default values in the expected declaration) correctly. Thus,
`getRemainingParameters` should use it as well to determine the list of
parameters to be skipped in each generated overload
#KT-23910 Fixed
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
Local lateinit var differs in behavior from a simple local var,
and logic that relies of 'instanceof Local' checks assuming that all
instances of Local are simple local vars can produce faulty code
(as in KT-23260, where a local lateinit var was not explicitly put on
stack when passed as an argument to an inline function, thus causing
null propagation).
#KT-23260 Fixed Target versions 1.2.50
Mikhael Bogdanov