Before, no parent element was returned for an object literal inside a
private property initializer, as only the getter was considered as a
potential parent.
Relevant tests are added on the IDE side (see 'LightClassBehaviorTest').
The idea is the following: if the analysis for some strongly connected
component seems not to be converging, reanalyze it again considering
all backward edges (i.e. leading to cycles) pessimistic,
basically treating the corresponding calls as external ones.
This helps to have more reasonable results for not-converging components still leaving
the chance for them to converge optimistically first.
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.
Yahor Berdnikau