Previously it was considered that function references leaking to
the native world are being called at their definitions. This is wrong,
as it is impossible to deduce from the Kotlin code alone when they
will be called, so just simply assume them a part of the root set.
The bug might have happened on a failed to have been devirtualized
callsite as some of the potential callees might have been lost.
The commit solves the issue rather conservatively by simply adding
all those potential callees to the root set.
Because of the bug, hanging (detached from the graph) NewObject nodes
would be created. The escape analysis algorithm then happily would
decide to allocate them on the stack, thus spoiling the statistics
about actual percentage of objects allocated on the stack.
See: compiler/testData/asJava/lightClasses/
AnnotatedParameterInInnerClassConstructor.kt
The muted tests don't work with the (KT-53371, KT-53519)-related
changes. During this test happens an attempt to access unresolved
annotations via CustomAnnotationTypeAttribute.
Discussion: KTIJ-23547
Otherwise, `transformPropertyAccessor` from
`FirDeclarationsResolveTransformerForArgumentAnnotations` is
never called
See:
- compiler/testData/asJava/ultraLightFacades/properties.kt
- analysis/analysis-api/testData/symbols/symbolByPsi/
contextReceivers/contextReceiversOnProperty.kt
Calls checker was trying to read thread state while unlocking mutex in
unregister thread function. At this point thread is already
unregistered and reference to current thread node is dangling.
To avoid this, we nullify this reference in advance, as its anyway
explicitly passed to unregister function, not read from global.
finding local parent and create it on the fly, instead of the requested
class.
avoiding double processing of class members and properly handling
"innerness"
fixes localClassMetadata test problem with propLocal.<>.D
related to KT-53463 and KT-53464
needed e.g. to find proper (fake) override on calls on dynamic receiver
fixes test js/js.translator/testData/box/dynamic/equals.kt
when a declaration created on the fly (not loaded from FIR), we
have no good way (yet) to create a correct signature for it before
creating IR. And proper signatures are needed for Klib linking.
So here we create the declaration (function) twice, first time
to calculate proper signature and the second time again with correct
signature.
The approach is weird and should be unnecessary in the presence of the
stdlib, so should be doublechecked again in the future.
Igor Chevdar