Example from
box/inference/coercionToUnitForLambdaReturnTypeWithFlexibleConstraint
// FILE: TestJ.java
public class TestJ {
public static <T> In<T> materialize() { return null; }
}
// FILE: test.kt
class In<in T>
fun <T> inferred(e: In<T>?, l: () -> T): T = l()
fun box() {
inferred(TestJ.materialize<Unit>(), { null })
}
`materialize` has flexible type, both for `In<T>` and `T`.
When analyzing `{ null }`, collected type constraints include:
ft<Unit?, Unit> <: T (from ft<In<ft<Unit, Unit?>>, In<ft<Unit, Unit?>>?>)
By allowing the lower bound of flexible type, FIR resolution can visit
`{ null }` with the expected type Unit, which will lead to proper
coercion to Unit at the end.
Some multiplatform tests are compiled in single-platform projects:
- in kotlin-stdlib-jdk7
- in kotlin-stdlib-jdk8
- in kotlin-stdlib-js-ir. The latter is technically MPP but with a
single platform, so its common sources are not considered as common.
Pass information about common sources to test compilation tasks in order
to use OptionalExpectation annotations there.
Co-authored-by: Svyatoslav Scherbina <svyatoslav.scherbina@jetbrains.com>
This is a workaround for the problem KT-43321.
Introduce an intermediate abstract set specialized for Map.Entry elements
and implement 'contains(Map.Entry)' method there.
Then inherit that intermediate set in entrysets of JS HashMap,
JS LinkedHashMap, JVM MapBuilder, that are specialized for
MutableMap.MutableEntry elements, so that no override of 'contains' is
required anymore.
This allows to avoid incorrect special 'contains' bridge being generated
that otherwise rejects all arguments except ones of MutableEntry type.
If project directory does not exist and out-of-process execution is used
the file with compiler arguments should be created in project directory
(if exists) or in temp directory.
#KT-43740 Fixed
IC caches could be modified and read from different threads.
In JPS builder these threads are RMI worker (invoked from Compiler
Daemon) and JPS worker thread. Proper synchronization fixes cases
when caches could become broken.
#KT-42265 Fixed
#KT-42194 Fixed
#KT-42265 Fixed
#KT-42937 Fixed
Supported case then children of sealed classes could be declared
anywhere in a module. If list of classes implementing sealing class
changes the sealed class and all its inheritors should be recompiled
(now sealed class should be compiled together with children in order
to calculate all possible inheritors at compile time) and and
invalidated (as they could have when operators).
The existing backend restores LVs and parameters from the suspend lambda
fields used for spilling between suspension points, hence they are
visible in the debugger as local variables, plain and simple.
This PR introduces the same pattern to the IR backend, to bring the
debugging experience in line with the existing backend.
Both backends are still at the mercy of the liveness analysis
performed in the coroutine transformer where a liveness analysis
minimizes live ranges of entries in the LVT. E.g. an unused parameter
will be dropped entirely.
Adjusted existing test expectations accounting for the differences in
LV behavior.
The current backend uses direct field access to the backing field
instead of calling the companion object accessor, which calls
an accessibility bridge, which then gets the field for code such as:
```
class A {
companion object {
val s: String = "OK"
}
// f uses direct access to the A.s backing field.
fun f() = s
}
```
This change does the same for the IR backend.
Jinseong Jeon