This is done primarily for JVM interoperability, otherwise it's impossible to
inherit from CharSequence there. On JS subSequence at the moment just invokes
substring.
#KT-5956 Fixed
This is done for JVM interoperability. There's still a member function
String.get() and an extension function "get" on CharSequence
#KT-1730 Fixed
#KT-5389 Fixed
And String.length as well.
This is done for JVM interoperability: java.lang.CharSequence is an open class
and has a function 'length()' which should be implemented in subclasses
somehow.
A minor unexpected effect of this is that String.length() is now a compile-time
constant (it wasn't such as a property because properties are not supported in
compile-time constant evaluation)
#KT-3571 Fixed
This is not something that needs to be intrinsified. Note that compiler
optimizations are still possible and the fact whether 'indices' is a member or
an extension is irrelevant to the optimizer
- Cloneable is a trait with a single protected member 'clone', which is mapped
to java.lang.Cloneable on JVM
- 'clone' is non-abstract to be able to call 'super.clone()' in the
implementations. Also if you need your class to be Cloneable, most of the
time inheriting from Cloneable and calling 'super.clone()' will work
- hack 'super.clone()' in JVM intrinsics and TImpl delegation generation
- make arrays Cloneable, handle 'clone()' calls in the intrinsic
#KT-4890 Fixed
Metadata for KFunction classes is now longer serialized along with built-in
classes. This effectively means that it's no longer possible to find KFunction
classes via dependency on built-ins. There should be a kotlin-runtime library
in the specified classpath for reflection types to be resolvable.
A lot of tests were moved and changed, because tests on callable references
require stdlib in classpath from now on
Float.rangeTo(Long) and Long.rangeTo(Float) now both return FloatRange for
consistency with other binary operations between floats and longs which, in
turn, return float to be consistent with Java
This reverts commit 1d21ebf882.
Conflicts:
compiler/testData/builtin-classes.txt
core/descriptors/src/org/jetbrains/jet/renderer/DescriptorRendererImpl.java
Reverting a part of this (related to the field 'prettyFunctionTypes') because
will need to add a test that deserialized built-ins (obtained by
KotlinBuiltIns.getInstance()) are consistent with lazy resolved built-ins. This
test would break because while DescriptorRenderer renders pretty function types
it compares descriptors to the ones from KotlinBuiltIns, but in case of lazy
resolve descriptors created for built-ins would be different from
KotlinBuiltIns, so renderer wouldn't correctly render a function type
Pavel V. Talanov