An expect class might lack some details and thus seem incorrect to the
compiler, while the corresponding actual class is totally fine.
Due to the specifics of the compiler, this happens more often then it
should (because the compiler actually always analyzes expects along
with actuals, with most references actualized).
For example, in KT-52882 the compiler analyzes an expect class
(TestImpl), but the class refers to the actual interface Test as its
supertype, meaning that the compiler sees TestImpl as a class inheriting
an Objective-C protocol but not an Objective-C class, which is
prohibited. While the actual class has its super types in order.
So, in reality, from both actualized and non-actualized points of view,
the code is totally correct, and the error was reported only because of
the way the compiler handles multiplatform.
Those compiler checks only matter for the actual class anyway, so
disabling them for expect classes is harmless.
^KT-52882 Fixed
This API was inspired by kotlinx.coroutines and shall help
making Kotlin Gradle Plugins 'Future' type more applicable for situations
when the Future is used inside the Configuration Phase
^KT-60158 In Progress
FIR-tree for scripts is built either for KtScript or KtFile depending on
the file structure. The presence of import statements results in KtFile.
There are lazy trees (some nodes are stubs) that are not yet supported
for scripts. We build such ones for KtFile case.
This commit prevents lazy tree construction for scripts at references
shortening.
^KT-59801 fixed
The error occurs when completing the
call for the outer synthetic call
`ACCEPT_SPECIFIC_TYPE`. The error
is saved into the CS of this outer
candidate, which leads to its
callable reference to be an error
reference, but since such calls are
not parts of the FIR tree, we never
collect such errors.
^Fixed KT-59233
NB: In general, it's unclear what to do in cases
like the following one, even when sometimes
we could, indeed, prefer something:
```
fun foo(a: Int, b: String, c: Boolean)
fun foo(b: String, c: Boolean, a: Int)
foo(c = false, b = "", a = 0)
```
^KT-55933 Fixed
Ignore, because `@JvmDefault` is deprecated
and we don’t even have tests for it, and
the new
``@JvmDefaultWith[out]Compatibility` only
allow classes as their targets
Mikhail Glukhikh