This lead to an exception being thrown frequently
Proper fix would be to prevent binding context from being corrupted
Known cases are hard to debug/reproduce
#EA-101081 Fixed
After this change, optional expected annotations will be compiled to
physical class files on JVM, and stored to metadata on other platforms,
to allow their usages from dependent platform modules. For example:
@OptionalExpectation
expect annotation class A
When compiling this code on JVM, A.class will be produced as if the
class A did neither have the 'expect' modifier, nor had it been
annotated with OptionalExpectation. Note that if there's no actual
annotation class for A, then usages (which can only be usages as
annotation entries) are simply skipped.
Class A will be public from Kotlin's point of view (since it should
be possible to use it in Kotlin sources), but _package-private_ in Java
to disallow its usages outside of the declaring module.
#KT-18882 Fixed
#KT-24617 Fixed
In some cases when several bridge methods are generated, their order
is undetermenistic. For example for class ClassLowerWithContext in the
following example
```
interface IrElement
class IrClassContext
interface IrElementVisitor<out R, in D> {
fun visitElement(element: IrElement, data: D): R
}
interface IrElementTransformer<in D> : IrElementVisitor<IrElement, D> {
override fun visitElement(element: IrElement, data: D): IrElement =
element.also { throw RuntimeException() }
}
abstract class ClassLowerWithContext : IrElementTransformer<IrClassContext?>
```
kotlin compiler synthesizes two additional bridges:
public IrElement visitElement(IrElement, IrClassContext);
[bridge] public Object visitElement(IrElement, Object);
[bridge] public IrElement visitElement(IrElement, Object);
Unfortunately the behavior is not deterministic and not easy to reproduce.
Generate continuation type as kotlin.coroutines.Continuaion. This code will
fail at runtime since there is no stdlib backing this change yet.
However, in order to generate compatible stdlib we need a compiler, which
generates continuation type as kotlin.coroutines.Continuation.
Thus, firstly we support the change in the compiler, make it bootstrap
compiler and only then change stdlib and tests accordingly.
#KT-23362
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
For some reason, this logic was a bit different in JVM (FunctionCodegen)
and JS (FunctionBodyTranslator). For example, in JS the
EXPECTED_FUNCTION_SOURCE_WITH_DEFAULT_ARGUMENTS_NOT_FOUND diagnostic was
reported even in the case when no expected function was found for the
actual function at all, which made it quite difficult to write
multiplatform sources for JS stdlib where it both should be compiled as
a part of the multiplatform project, and by itself (suppressing
NO_ACTUAL_FOR_EXPECT): in the latter case, the new error must have been
suppressed everywhere as well
#KT-21913
Draw a clear distinction between the referenced function's parameters
and the anonymous synthetic function's parameters (see the comment).
This will be useful in supporting advanced callable reference features
like KT-8834
Also move internal declarations from runtime.jvm module into new package
kotlin.coroutines.jvm.internal in stdlib
The necessity of these declarations being in built-ins is controversial,
but also it will complicate the migration of current coroutine runtime
to a separate jar if we ever need this
- move getDelegates from CodegenUtil to DelegationResolver, reuse it in
DelegationChecker
- use getAllOverriddenDescriptors + filterOutOverridden instead of a manual DFS
Mikhael Bogdanov