For ordinary functions mapSignature doesn't use original descriptor
and maps the given descriptor itself, but for constructor it obtained
the original value parameters.
Necessary `getOriginal` calls were added to the call-sites
It should not affect the semantics, because mapSignatureWithCustomParameters
can only be called with FunctionImportedFromObject from mapSignature.
At the same time it's very nice to have all of these kinds
of custom unwrapping in the same place
There's no need in unwrapping for TypeAliasConstructorDescriptor
because mapSignatureSkipGeneric/mapDefaultMethod already do it
in some moment, and ConstructorDescriptor has getConstructedClass method
for mapping its owner
The problem was that when resolving super-calls we used known substitutor
when creating a type alias constructor, thus its original return itself,
while it's expected that it should return the descriptor before substitution
The main idea of the fix that `createIfAvailable` should always return
unsubstituted constructor.
Note that known substitutor for type alias constructor should be based
on abbreviation.
The test change seems to be correct as PROJECTION_IN_IMMEDIATE_ARGUMENT_TO_SUPERTYPE
is already reported.
Beside this, resolution behavior isn't expected to be changed dramatically
The problem is very subtle (see the test): when generating a signature
for an object literal we also were mapping its super-class
(a type alias here).
Although we did unwrap its underlying constructor to map it properly
we did too late (after obtaining value parameters from the type alias constructor descriptor).
Another problem is that TypeAliasConstructorDescriptor.getOriginal
in the case does return itself, while it's expected to return
unsubstituted version
Note: everything works for common calls for such constructors
because they mapped through mapCallableMethod which contains
another custom unwrapping of type alias constructors
#KT-16555 Fixed
(it can be different from 'getContainingDeclaration()' in case of type alias constructor).
KT-15109 Subclass from a type alias with named parameter in constructor will produce compiler exception
KT-15192 Compiler crashes on certain companion objects: "Error generating constructors of class Companion with kind IMPLEMENTATION"
1. Analyze method node with fake jumps for loops to make sure that
all instructions reachable only through break/continue jumps are processed.
2. Fix stack for break/continue jumps.
3. Drop fake jumps for loops, analyze method node again.
4. Fix stack for try/catch and beforeInline.
Instead of requiring to pass it in SerializerExtensionBase's
constructor, pass it always in serializePackage. This is more
straightforward and helps in a situation where one SerializerExtension
instance is used for the whole module, not one per-package
Before this change such wrapping happened only during coercion,
i.e. when a call-site expected a KClass instance.
But when call-site expects Any, for example, no wrapping happened,
and raw j.l.Class instance was left on stack.
The solution is to put wrapping code closer to generation of annotation's
method call itself to guarantee that necessary wrapping will happen.
#KT-9453 Fixed
Finnaly markers are used only for non-local return processing and are removed after inlining to non-inline functions, same deletion should be performed on inlining to anonymous objects
#KT-16532 Fixed
The problem was that he number of mask parameters for defaults when
generating methods declaration was being calculated upon resulting signature
(with additional parameters: extension receivers, enum name/ordinal),
while on call-sites the masks number was calculated by the arguments number
in resolved call, i.e. by the number of real value parameters.
And because of the additional synthetic parameters (like enum.ordinal) these
two numbers could be different.
The solution is just to use value parameters number in both places.
Note, that we only count value parameters from the original sourse
declaration, ignoring synthetic ones generated by backend (e.g.
Continuation for suspend functions)
#KT-14565 Fixed
See the issue and the test. The problem was that when generating
call to `foo` method in member scope of `AT<*>` its resulting descriptor
after substitution and approximation was: fun foo(x: Nothing..Array<out Nothing>).
This signature is correct, but when using this parameter type
for generating a vararg argument the assertion is violated that
the type of the argument must be an array
(by default we're using lower flexible bound everywhere)
The solution is using upper bound for flexible types that should
always have a form of Array<out T> for varargs (even for such corner cases)
both for Kotlin and Java declarations.
#KT-14607 Fixed
The problem was that when obtaining char from the wrapper,
codegen used int as expected type that led
to a ClassCastException: java.lang.Character cannot be cast to java.lang.Number
The solution is using coercion to chars, it's still correct,
because of implicit widening coercion in JVM from C to I
#KT-15105 Fixed
The problem was that anonymous classes wasn't regenerated
although they capture another anonymous class that is a subject
for regeneration
#KT-8689 Fixed
The problem was that for property getter 'context.getContextDescriptor()'
references the containing property, while 'context.getFunctionDescriptor()'
the accessor itself
#KT-15594 Fixed
The main problem here is that moduleName that is being passed to KPackageImpl
is useless: as can be seen in
ClosureCodegen.generateCallableReferenceDeclarationContainer, the name of the
current module is always written to the class file for a callable reference,
not the name of the module of the referenced declaration. This resulted in
reflection not loading the correct .kotlin_module file and subsequently not
finding the required file facade for a top-level function.
The commit does not fix the issue with the incorrect module name written in the
back-end, but workarounds it. It turns out, reflection can figure out the name
of the module of the referenced declaration itself by parsing the header from
the given java.lang.Class object for a single-file/multi-file package facade
and extract the package_module_name protobuf extension. Similar code was
already there in Member.getKPackage() in ReflectJvmMapping.kt but it did not
support multi-file classes, of which there are a lot in the standard library;
this is now supported
#KT-12630 Fixed
#KT-14731 Fixed
getDispatchReceiver/getExtensionReceiver always return not-null value,
but in the absence of receiver this value is equal StackValue.none(), i.e.
has a size 1
The tests were passing because of the problems with the test framework:
4b9e20ab8c
Previous version of the boxing/unboxing analysis treated merging boxed and non-boxed values as a hazard.
If such merged values are not used (e.g., early return + local variables reused in inlined calls),
corresponding boxing/unboxing operations still can be optimized out.
All information related to boxed value usage by instructions is moved to 'BoxedValueDescriptor'.
Introduce "tainted" (and "clean") boxed values, with the following rules:
merge(B, B) = B, if unboxed types are compatible,
T, otherwise
merge(B, X) = T
merge(T, X) = T
where
X is a non-boxed value,
B is a "clean" boxed value,
T is a "tainted" boxed value.
Postpone decision about value merge hazards until a "tainted" value is used.
Since annotations are a part of the declaration, they must have the same
visibility as the declaration in the bytecode. Otherwise obfuscators like
Proguard might strip the "$annotations" method and no annotations would be
found via Kotlin reflection
#KT-15993 Fixed
Use proper initial/frontend version of suspend descriptor
when writing METHOD_FOR_FUNCTION, because serializer uses this version
Also this commit contains adjustments of neighboring code to the describe
change
#KT-16093 Fixed
While within a method by the JVM spec null-value has a special
Nothing-like type, when we spill it for a coroutine, we must choose
some real type to CHECKCAST to after restoring the variable's value.
But the problem is that such a real type depends on usage of that null value,
and there may be more than one usage.
The solution is not to spill such variables into fields, but instead
init them with ACONST_NULL after each suspension point
#KT-16122 Fixed
Dmitry Petrov