KT-2873: VerifyError on instantiating a local class inside a closure
KT-3210 Inline Class: CompilationException: Back-end (JVM) Internal error: wrong code generated java.lang.ArrayIndexOutOfBoundsException null
#KT-3389 Fixed
- use ResolvedCall where possible
- 'call' parameter to invokeMethodWithArguments was used only to generate
callee, e.g. in "A()" where A is an expression which can be invoke()'d.
In case of constructors and enum entry delegation specifiers there's no need
to generate callee, so 'call' is made Nullable with a subsequent assert
- remove generateJavaConstructorCall() method, since it did no useful work.
Java constructor invocation is broken anyway and needs to be fixed (KT-3532)
- minor code style / formatting issues fixed, several methods renamed to better
reflect semantics
- make several commonly used parameters ClosureCodegen's fields
- take an arbitrary strategy for closure function body codegen
- don't make extra binding context lookups
Instead of invokevirtual on FunctionImpl class, do invokeinterface on a
Function trait. This will allow to invoke functions on classes which don't
inherit from FunctionImpl classes.
Also rename the method to the more sensible name
- CLASS_FOR_FUNCTION slice was used for two purposes: to record closure classes
for functions and for scripts. Separate this slice into two slices:
CLASS_FOR_FUNCTION and CLASS_FOR_SCRIPT
- add classNameForAnonymousClass() overloaded method to CodegenBinding, taking
a function descriptor (not a PSI element)
Extract some methods, replace types with more generic (ExpressionCodegen ->
LocalLookup), make more stuff fields instead of parameters passed to every
method, annotate with Nullable/NotNull
Superclass of closures should now be FunctionImplN instead of FunctionN. Since
these -Impl classes are needed only in JVM, the corresponding descriptors and
types are created in the back-end only.
generateMethodBody() is now responsible for generating the local variable
table, therefore the data class MethodInfo is not needed anymore to return
multiple values from it
Always map descriptor to the callable method and take the signature from there,
since this way the signature appears to be more accurate. The whole
"mapSignature vs mapToCallableMethod.getSignature" story needs some
investigation though.
Also make the method non-static, remove useless checks, etc
Use FunctionCodegen and the newly created FunctionGenerationStrategy to
generate the needed instructions. Make some methods in FunctionCodegen private
since they're not used anymore outside of the class
Create a new class FunctionGenerationStrategy, which is used to specify exactly
how the body of a function will be generated. This is made primarily to factor
out the hard dependency on PSI in FunctionCodegen.generateMethod(). The PSI
element is now optional and is only used for debug information (as an argument
to newMethod() and endVisit()). This also helps to refactor the confusing logic
about generating default property accessors.
Assert for whether we generate code now for the declared member is now useless,
since generateMethod() will be used also for generating any possible members.
Also surround with "if ( != null)" some method call in genJetAnnotations(), as
null is possible here
Check if we need to generate code before calling generateMethod()
There were 4 such checks, 2 of them in PropertyCodegen, one in
FunctionCodegen.gen() and one in ClosureCodegen. Every usage except the last
was prepended with the check
Mikhael Bogdanov