Do not generate stubs if there is no special bridge in the current class
- there are already Kotlin super class in hierarchy
- special bridge has the same signature as method itself
#KT-11915 Fixed
Encapsulate everything that is needed in checkers into CallCheckerContext. Pass
an instance of this context instead of BasicCallResolutionContext to checkers.
Also pass an instance of the element to report errors on: this is useful
because before this, every checker had its own way of determining where should
the error be reported on. Some of them, for example, were not doing anything if
Call#calleeExpression returned null, which is wrong, see operatorCall.kt
#KT-12875 Open
The problem is that
`override fun remove(element: E): CollectionWithRemove<E>`
seems to be illegal from Java's point of view, while it's OK for JVM
These declarations have the same signature (return type is isgnored)
- override fun remove(element: E): CollectionWithRemove<E>
- override fun remove(element: E): Boolean
When we meet such declaration we choose random declaration for fake override in synthetic class
that may lead to signature clash
Previously its call sites needed to determine if the receiver type should be
ignored (e.g. if the reference is to static member or nested class constructor,
or if it's a bound reference), and 3 of 4 callers did it incorrectly. Simplify
this by passing the DoubleColonLHS instance everywhere.
Also rename it to createKCallableTypeForReference
#KT-12738 Fixed
#KT-12751 Fixed
#KT-12799 Fixed
Get rid of trace & reportOn parameters of
createReflectionTypeForCallableDescriptor: move the two checks that required
them to DoubleColonExpressionResolver and combine with other checks into a
single function that checks the validity of the referenced symbol. This also
makes these checks reported only once when invalid expressions are passed as
function arguments (previously they were also reported from
getResolvedCallableReferenceShapeType).
Also inline getReflectionTypeForCandidateDescriptor after this, and refactor
its usages
As well as all other kinds of expressions
While it's not necessary in a sense that 'for' loop can not be plain expression,
i.e. it can't be an argument for safe-call etc., but laziness is still very convenient property.
E.g. within attached test they were generated twice in case of last expression
of coroutine block, because coroutine related codegen part is built upon
assumption that all expressions should be generated lazy.
A lot of additional work was required to support them:
- Suspension points are being identified by two markers
instead of one pointing to suspend function call
- Approach with replacing return type of suspend function does not work anymore.
So we decode suspension return type as an argument for begin marker
- It became necessary to perform variables liveness analysis
(see comment in org.jetbrains.kotlin.codegen.coroutines.CoroutineTransformerMethodVisitor.spillVariables)
Denis Zharkov