Before this change we set JsSwitch source to subject's JsExpression.
We ignore these types of source elements during:
1. js ast serialization (see 'JsAstSerializer.extractLocation');
2. source map generation (see 'SourceMapBuilderConsumer.addMapping').
However we might add indent during source generation
(see 'JsToStringGenerationVisitor.pushSourceInfo').
That seemingly broken 'testEnumEntryRemoved' in
'IncrementalJsCompilerRunnerTestGenerated.ClassHierarchyAffected',
because deserialized ast during incremental build would not
have source element at all (JsExpression was ignored), but ast
during rebuild would have JsExpression source element.
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
Having to invoke `exist` so prevent a runtime exception
is no better then trying to invoke a method on a null
reference. It is actually worse, because Kotlin type
system handles the latter.
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
Roman Artemev