tree 8af8bda1fd890328589f114e84e0a9eee574954b
parent 4c4cbacf8e088a6d5c32b038366301d393b2dd12
author Yan Zhulanow <yan.zhulanow@jetbrains.com> 1738077962 +0900
committer Yan Zhulanow <yan.zhulanow@jetbrains.com> 1740488300 +0900

[Analysis API] Resolve JVM counterpart callables on STATUS

Certain kotlin-stdlib classes are mapped to classes from the JDK,
such as, 'kotlin.collections.Collection' maps to 'java.util.Collection'.

Use-site scope of mapped classes provides 'JvmMappedScope' as a declared
member scope. On iteration over supertype callables performed during
the STATUS phase ('FirStatusResolver.getOverriddenFunctions'),
'JvmMappedScope' processes callables across both Kotlin and Java
hierarchies.

While STATUS in the LL FIR force-resolves callables of Kotlin supertypes
('LLFirStatusTargetResolver.resolveClass'), callables back-mapped from
Java supertypes stay intact. E.g.:

```
kotlin.collections.Collection: kotlin.collections.Iterable // handled
// is mapped to
java.util.Collection: kotlin.collections.MutableIterable // not handled!
```

The fix performs additional resolution for mapped stdlib classes,
analyzing callables from both Kotlin and Java type hierarchy.

The problem is specific to the Kotlin compiler project where stdlib
classes come in sources. In other projects, the kotlin-stdlib is already
compiled, so no JVM-mapped require analysis.

^KT-74740 Fixed

(cherry picked from commit 0a7ba1a5760794d606d27d317095cc42fb39c5b6)