There is a lot of changes about closures calculating and generating.
1. As classes can have more than one constructor each of them should
have closure arguments.
2. Captured variables set is the same for all of them.
3. Within constructors bodies/delegating calls closure parameters
should be accessed through method arguments because fields may be
not initialized yet.
The fqname of class should be clear from code
Example: can't shorten A.Default.B.Default.C to A.B.C
Also fixes problem when nested class of enum class could be accessed via enum entry
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
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
The main problem of the previous approach was that we were only generating
erased method signatures, which was incorrect in case a class also had a member
from another supertype with the same signature as the substituted one from the
collection. Javac issues compilation errors when compiling Java code against
such classes.
Also all the needed method stub signatures were hardcoded in
generateBuiltInMethodStubs() and the case of MutableListIterator was missing
Don't use CodegenUtil#getDeclaredFunctionByRawSignature because it's incorrect
in case of platform types. Instead use JetTypeMapper to find JVM signatures of
methods which are callable on the current class
#KT-6042 Fixed
Denis Zharkov