JS scripting uses the old IR to JS transformer.
The new IR to JS transformer can not be used for
JS scripting out of the box. Patching the new transformer for
JS scripting is potentially dangerous and requires a lot of effort.
Dropping JS scripting and the old IR to JS transformer allows to
refactor and simplify JS BE codebase.
- Huge refactoring for IC
- Update hash combination logic
- Introduce value class for IC hashes
- Calc md5 directly by function IR
- Split IC logic by classes
- Move JsIrLinkerLoader into separate file
- CacheUpdateStatus is a sealed class
- Render TYPE_PARAMETER reified flag
^KT-51081 Fixed
^KT-51084 Fixed
We are going to deprecate `WITH_RUNTIME` directive. The main reason
behind this change is that `WITH_STDLIB` directive better describes
its meaning, specifically it will add kotlin stdlib to test's classpath.
Descriptors are already supposed to be sorted in scopes. The problem is
that rendering descriptors for sorting takes a lot of time (~1.5% of
total compilation time of intellij with JVM IR), and simple heuristics,
like comparing by names first, don't fully help with it.
#KT-48233
```
fun <T : Any> CHECK_NOT_NULL(x: T?): x =
if (x != null) x else throw NullPointerException(...)
```
This allows to compile both Kotlin/JVM and Kotlin/JS effectively.
In constructs such as 'd[i] += x', where both indexed get and indexed
set are dynamic calls, it's safe to generate augmented assignment body
directly, without temporary variables for array ('d') and index ('i').
Note that corresponding IntermediateValue's are OnceExpressionValue's,
which would throw an exception if this assumption is violated.
NB1 Not every dynamic unary or binary expression is translated to
dynamic operator expressions literally. For example, assignments and
increments can have safe calls in LHS, which require some extra logic.
NB2 There are some open design questions left regarding how dynamic
expressions should actually be translated.
Dmitriy Novozhilov