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).
*given that it runs on JDK7 and higher. The addSuppressed member
is called with reflection when it's available.
kotlin-stdlib-jdk7 extension still overrides that and calls
addSuppressed member statically as before.
#KT-30560 Fixed
These tests ensure how compiled jdk6 binaries work in newer JDK7/8 environment,
and most likely the stdlib-jdk7/8 artifacts will be in that environment.
This reverts test classpath change (accidentally?) made in the commit 99f2cc3d.
In TopDownAnalyzerFacadeForJVM, we now always use the "load built-ins
from module dependencies" behavior that was previously only enabled with
the dedicated CLI argument -Xload-builtins-from-dependencies. However,
sometimes we compile code without kotlin-stdlib in the classpath, and we
don't want everything to crash because some standard type like
kotlin.Unit hasn't been found.
To mitigate this, we add another module at the end of the dependencies
list, namely a "fallback built-ins" module. This module loads all
built-in declarations from the compiler's class loader, as was done by
default previously. This prevents the compiler from crashing if any
built-in declaration is not found, but compiling the code against
built-ins found in the compiler is still discouraged, so we report an
error if anything is resolved to a declaration from this module, via a
new checker MissingBuiltInDeclarationChecker.
Also introduce a new CLI argument -Xsuppress-missing-builtins-error
specifically to suppress this error and to allow compiling code against
compiler's own built-ins.
#KT-19227 Fixed
#KT-28198 Fixed
pyos