This option has no effect on the production code. But in a custom
scenario of a local bootstrap, where the compiler is replaced with the
one where JVM IR backend is enabled by default, this option allows to
switch back to the old backend.
All of these arguments (except the one for compiling experimental
coroutines) are supposed to go away as soon as we fix related problems
in the JVM IR backend.
* In the Kotlin/JVM tasks, move the compiler arguments setup logic to
a separate class, so that it can be reused by the Kapt tasks without
directly referencing the Kotlin/JVM tasks
* In the Kapt tasks, carefully capture the values using the Provider API
so that the task can be serialized for Instant Execution and then
deserialized and executed without relying on the project model
Issue #KT-35181 Fixed
The problem in the added test was that a suspend lambda was represented
by a function reference with a bound argument for the ObjectRef value,
and the corresponding parameter was not the first parameter of the
referenced local function. This happens because
LocalDeclarationsLowering lifts the local function up and adds a
new parameter for the captured ObjectRef (which is bound at the call
site), but the original receiver parameter remains the first unbound
parameter. So, it's no longer correct to rely on the fact that all bound
parameters of a function reference are located in the beginning of the
parameter list, which was kind of assumed in the `withIndex` call in
`AddContinuationLowering.addCreate`.
when transforming objects with suspend functions/lambdas, which
capture crossinline suspend lambdas. Since functions with the
suffix have a counterpart without the suffix, for java interop
and reflection call purposes, it is safe change.
#KT-31242 Fixed
In case of null qualifier, we should not look into any static scope
NB: factory::createCallableProcessor returns NoExplicitReceiver processor
in case of null-receiver, that makes resolving the call in the test as
`property(::key)` that matches to the property itself, thus leading to
overload resolution ambiguity
^KT-35887 Fixed
For users that have Gradle's build cache [1] enabled, make NodeJsSetupTask
and YarnSetupTask cacheable to avoid the distribution archives being
downloaded again if they have been downloaded before by other builds of
other projects that apply the Kotlin plugin.
[1] https://docs.gradle.org/current/userguide/build_cache.html
Smartcasts between partial and full resolution mode should almost never match,
comparing smartcasted types in test runner is incorrect in general case.
Mute failing test until decision about correct behaviour (KT-35922).
`BindingContext.getType`'s behaviour on argument expression has been different for OI and NI for some time.
New inference used to rewrite argument's type after smartcast, which led to missing subsequent smartcasts in some cases.
This commit makes retrieval of smartcasted argument type explicit.
Expression type serves as a part of a key for retrieving smart cast info.
Rewriting expression type with SmartCastManager leads to incorrect processing of following smartcasts for same expression, therefore it was removed.
KT-32507 Fixed
KT-32358 Fixed
It's necessary because of new type substitutor is eager than odl, so
if there is a substitution of type parameter deep inside type arguments
then second substitutor wins against first
#KT-35896 Fixed
Ilya Gorbunov