For example,
KMemberFunction2<T, P1, P2, R> : KMemberFunction<T, R>
So for this inheritance the heuristic that was present ("take the last K type
parameters of the subclass, and substitute for K parameters of the superclass")
was wrong. The new heuristic for this case is: take type parameters with the
same names.
Also don't store "parameters" in a lazy value, since it's easy to compute and
it's computed practically every time anyway
It's needed to prevent NPE when requesting non-nullable visibility of descriptor
before `initialize` has been called.
Currently it happens because of indirect calls of `DescriptorUtils.isLocal`
between descriptor creation and it's initialization.
Non-member descriptors, e.g. type parameters, value parameters that defined in local function should be local too
Otherwise a lot of exceptions happens when resolving references within anonymous objects
Users' Java code will not break in common cases (when passing functions to
Kotlin), and deprecation warnings will be reported.
Provide an inspection with a quick fix which allows to replace deprecated
function class usages to the new classes. Include this fix to the "code
cleanup" action
Introduce abstract class FunctionReference, which is supposed to be a
superclass for all anonymous classes generated for function references. Each
anonymous subclass will have statically-generated symbol info, which will be
used by reflection to locate the symbol
It has its arity precomputed, as opposed to the future KFunctionImpl inheriting
from FunctionImpl, for which the computation of arity can take some time and so
it shouldn't be passed in the constructor and saved as a field
Add a file in package 'kotlin.jvm.functions' to the project and replace
explicit imports of functions 'kotlin.Function{n}' to two imports 'kotlin.*'
and 'kotlin.jvm.functions.*', so that the codebase can be compiled both by the
old and by the new compiler
Reflection interfaces (interfaces in kotlin.reflect.* in core/builtins/) are
now fully considered as built-ins and can be accessed via KotlinBuiltIns. This
increases runtime size by ~20kb, but only because KotlinBuiltIns is static and
is therefore constructed only via resource loading from the compiler classpath
at the moment. As soon as it's possible to inject KotlinBuiltIns to the
particular resolution process, the metadata on JVM will be loaded via standard
annotation mechanism (kotlin.jvm.internal.KotlinClass/KotlinPackage) and wasted
runtime space will be reclaimed
Add storageManager to ModuleDescriptorImpl (to be used later)
Extract ModuleParameters to hold default imports and platform class map
Introduce MutableModuleContext to simplify module creation code
Alexander Udalov