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
This may be more correct in case of complex cross-module inheritance, where
overridability should be detected by structural equality of signatures instead
of referential equality of constructed descriptors (no test added because it's
not so easy to come up with an example)
To simplify migration from 1.0 to 1.1, do not allow data classes to
automatically implement abstract equals/hashCode/toString declared in
super-interfaces (KT-11306) if "-language-version 1.0" is specified
Change getAllOverriddenDescriptors contracti, now it returns
original (not substituted) descriptors without any duplicates.
First of all it's necessary in CodegenUtil.getDelegates to avoid
duplicates (see assertion there), but also it's convenient for all
other usages of this method
#KT-8154 Fixed
Denis Vnukov