Unavailable Java members from mapping J2K in stdlib

[vmishenev]

interface MyCharSequence: CharSequence

This has chars() and codePoints() members that are absent in https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-char-sequence/ (and in the new documentation too) since they come from mapping (see https://kotlinlang.org/docs/java-interop.html#mapped-types) Java to Kotlin/Kotlin to Java.

The actual DRIs of chars() and codePoints() have thekotlin package so after fixing #3529 they lead to non-existent https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-char-sequence/chars.html and https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-char-sequence/code-points.html

This is also relevant to https://github.com/Kotlin/dokka/issues/2879 (e.g. Dokka generates .../kotlin-stdlib/kotlin.collections/-collection/parallel-stream.html that is a 404-page)

Possible expected behaviour

• StdLib documentation should generate such pages
• DRI should lead to Javadoc documentation, in this case, https://docs.oracle.com/javase/8/docs/api/java/lang/CharSequence.html#chars-- and https://docs.oracle.com/javase/8/docs/api/java/lang/CharSequence.html#codePoints--

[vmishenev]

The compiler provides the ability to call methods through Kotlin types that are not declared in them, but are present in platform Java types.

There are 3 kind of declarations that come from mapping J2K in the JVM platform:

• approved by the Kotlin team;
• hidden and it is impossible to call them;
• can be called, but the call will be marked deprecated.

Example: getFirst is from JDK 21 in java.util.List

In the first possible solution, Dokka should show only declarations approved by the Kotlin team.

[vmishenev]

The list of such functions with their status is here. The list of mapped types is here

In K2, there is a class that is responsible for providing a mapped Java scope. Also, see wrapScopeWithJvmMapped

[vmishenev]

Dokka should filter out filter out such methods from documentation since:

1. they have no available doc;

2. In K1, we experience some inconsistencies during the analysis of stdlib. For example, Collection does not contain such methods (e.g. spliterator, stream, parallelStream), but its inheritors (AbstractMutableCollection) do. It seems Dokka will have the similar situation in K2.

The long-term solution in K2 is blocked by https://youtrack.jetbrains.com/issue/KT-69796/Analysis-API-Provide-a-way-to-detect-mapped-methods-from-JVM

The short-term one is to support a manual list of such methods in a Documentable filter. e.g. https://github.com/vmishenev/kotlin/commit/8997a9ad31446024f00428bda634edeb40d270e3