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
Use reflection in ProgressionUtilTest instead of calling methods on the class
from the class path, because in the latter case we were just testing
ProgressionUtil from bootstrap runtime (which, presumably, always works
correctly since it's a bootstrap distribution)
With this change, compilable built-ins (under core/builtins/src) are fully
written in Kotlin
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 is needed because until we have modules and dependencies implemented in
our IDEA plugin, the whole project always is analyzed to highlight any file in
the project. This resulted in weird errors in different modules in Kotlin
project because two declarations were found for each built-in class: the one in
kotlin-runtime.jar and the one (totally unrelated) in the 'builtins' module
BuiltInsSerializer now serializes built-ins found in two source roots:
core/builtins/native and core/builtins/src
Add return types to some declarations in core/builtins/src, because now that
BuiltInsSerializer processes them, it launches lazy resolution which can't
always deduce the return type
'builtins' will be used for platform-independent core built-in definitions,
'runtime.jvm' for things that should be present at runtime in order for Kotlin
code to execute correctly on JVM
ProgressionUtil goes to 'builtins' right now because progression iterators
depend on it, but should be rewritten to Kotlin later
Alexander Udalov