`jsArguments()` is lowered into a reference of the `arguments` object.
This is useful for extracting varargs, when calling Kotlin code from
JavaScript. For a concrete example, see KT-15223.
This is needed to 1) avoid ambiguity about the type of linkage used in Kotlin/Native compiler, 2) have the same exception name in JS and Native backends.
^KT-50775
Some sources for kotlin-stdlib-js-ir are not copied to build dir
and used directly from the project.
Modify kotlin.test/js-ir as well, while there's no evidence of the
problem so far.
Should be removed after KT-50876 fix.
^KTI-730 In Progress
Intentionally use doFirst section to trick gradle and not affect
inputs with absolute path usage.
Old behaviour can be returned by kotlin.build.use.absolute.paths.in.klib
in local.properties
Should be removed after KT-50876 fix.
^KTI-730 In Progress
This method was used for coercing `Long` values to JavaScript
`number`. However, it caused issues when `Long` values were
concatenated to a string (see KT-8666, KT-26706).
- Reuse JS IR Suspend function lowering
- Fix types
- Disable reinterpretCast-based optimization for inline
classes
- Add basic support to Wasm stdlib
- Explicitly transform suspend functions into regular functions
with continuations
- Clean suspend function handling from JS IR codegen
[JS IR] Fix type check utils to work with array of arities
[JS IR] Store multiple arities for suspend functional interface implementers
^KT-46204 fixed
These compiler arguments enable features which are enabled by default in
the current Kotlin anyway.
The only exception is in :compiler:cli which uses an old language
version.
Suppress "UNUSED_PARAMETER" to fix compilation warnings. Also suppress
"unused" to make the file less yellow in the IDE.
Also enable `-Werror`, unless Gradle property
`kotlin.build.disable.werror` is set to true.
If an accessor is not available at runtime we fall back
to the property access.
This is useful in cases when JS objects are casted to Kotlin
classes implicitly. This pattern did work in the old BE, which
lead to a significant amount of code which doesn't work anymore.
- Int.toChar was left non-deprecated because the replacement is not intrinsic yet.
- Number.toChar was left non-deprecated because otherwise the deprecation propagates to the override, Int.toChar.
KT-23451
* Make IntelliJInstrumentCodeTask compatible with configuration cache
* Make CoreXmlShadingTransformer compatible with configuration cache
* Make :kotlin-reflect:relocateCoreSources compatible with configuration cache
* Copy some properties to not capture it's owning object into lambda to support configuration cache
Relates to #KT-44611
Artem Kobzar