annotation, data, enum, inner, open - classes supplied with these
modifiers cannot be sealed.
Commit fixes code completion - "sealed" is no longer suggested in
the mentioned case.
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
Igor Yakovlev