These overloads cover the most common cases of conversion of the entire
String or Byte/CharArray, avoiding extra index check and branching.
#KT-24810, KT-29265
- Port part of 'misc.js' from current backend to 'bitUtils.kt' in IR backend
- Enable toBits, toRawBits, fromBits extension function on Double and Float
- Enable Double.withSign
- Refactor getNumberHashCode using new utils
Function 'kotlin.js.js' is to be redesigned in JS IR backend,
partially because it is a hard feature to support.
Current implementation is unstable and can cause problems around
inlining and name generator. Luckily most of its use-cases
can be covered by simpler features like dynamic expressions and
external declarations.
Thus we are reducing it's usage in stdlib to make IR backend more
stable in current state. JavaScript features that can't be covered by dynamic expression are
implemented in 'jsOperators.kt' file respectively for each backend:
- 'internal inline' function which calls 'js' function inside for current
pre-IR backend
- 'internal' function with '_hack' parameters for JS IR backend which will be
later intinsicified in a compiler
KT-26398 had updated behavior from reference comparison to regular
equality, but the documentation for CoroutineContext was left out.
The whole "by reference" needs to be removed, because it now
follows default behavior of all Kotlin collections and need no
further clarification.
Stdlib annotation 'kotlin.internal.NoInfer' was redeclared in stdlib tests
so non-fried modules (kotlin-stdlib-jdk7, kotlin-stdlib-jdk8, etc.)
could access it.
IR deserializer does not support declaration duplicates (at least yet
for JS IR backend). Thus this commit removes this redeclaration and
suppresses errors on its usages instead.
Move kotlin-stdlib-js project and the sources specific to the current backend to 'stdlib/js-v1' directory,
but leave sources that can be shared with the new IR backend in the common 'stdlib/js' location
with exception for 'stdlib/js/src/generated', which is used exclusively for current backend.
This simplifies sourceset configuration when building stdlib with the new backend.
The extensions 'contains' and 'reversed' from kotlin.ranges can be more
specific for IntRange, LongRange, etc than the same functions from
kotlin.collections, yet they lose in overload resolution to the latter
ones when invoked from kotlin.collections package
because of same package package extensions are preferred (KT-30633).
Ilya Gorbunov