Package 'org.jetbrains.kotlin.idea.quickfix' already contains top level
functions in module 'idea-analysis' and top level functions in another module
cause compilation errors because of package facade class clash
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
Now that functions and extension functions conform to each other, this method
began to conflict with the synthesized SAM-adapter from the super class (which
also can't be overridden by design)
Apparently type annotations ('kotlin.extension' in particular) are lost
somewhere in control-flow values processor at the moment, so types may not be
as precise as they were when functions and extension functions had different
classifiers.
This test presumably only affects IDE functionality like 'Extract Method' in a
way that it will suggest a slightly incorrect function type for the parameter
of an extracted method. An issue is to be reported and fixed later upon demand
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 types are now considered to be built-in, so their absence means the
runtime is broken and the compiler can't work at all; this condition probably
should be handled on another level for all built-in types
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
Alexey Sedunov