Members declared in interface or overriding members declared in super-interfaces
can be implemented by delegation even if they override members declared in super-class
(NB for interface this can be only 'kotlin.Any').
(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.
Generate 'do-while' loop body as IrComposite, because variables declared
in loop body should be visible in loop condition.
Wrap 'do-while' loop in IrBlock so that variables declared in loop body
are not visible outside of the loop.
Generate 'while' and 'do-while' loops as expressions of type Unit.
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
Move 'generateExpressionForReferencedDescriptor' to CallGenerator,
use it in 'generateCall',
add PSI-free versions of some utility methods so that call elements can
be generated when we're already deep in ResolvedCall generation
and have forgotten about PSI.
There are two different tests: the one that checks that all versions are
consistent (but not equal, because some versions are major.minor.patch,
but some only major.minor), and the one that checks that versions of all
subprojects of the Maven projects are exactly equal (1.1-SNAPSHOT
currently)
#KT-16455 Fixed
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
When synthetic member comes not from the receiver type itself,
but from one of its supertypes it doesn't make sense to subsitute
the member with receiver type, we should obtain relevant supertype
and use it instead.
#KT-16578 Fixed
Set constructor return type in FunctionDescriptorResolver#createConstructorDescriptor
(it seems to be the only place where ClassConstructorDescriptorImpl#initialize(...)
is called, but returnType is not set).
Provide proper dispatch receiver parameter for delegated members.
Use dispatch receiver parameter for delegated members in IR generation
for delegated member body (and check that the receiver has corresponding type).
Dmitry Petrov