Incorrect link for inherited java method from collection

[vmishenev]

• In stdlib AbstractMutableCollection: the functions like spliterator, stream, toArray, toString point anywhere except that AbstractMutableCollection member pages: some point to AbstractMutableSet, some - to LinkedHashSet.

• Another reproducer (the unit test):

            
            import java.util.AbstractCollection

            abstract class MyCollection<E> : AbstractCollection<E>()

[vmishenev]

I have opened KT-56838

[IgnatBeresnev]

Might be related: #2464

[vmishenev]

KT-56838 is not a bug, it's a feature. It happens because of Java mapping. For our case: kotlin.collections.AbstractMutableCollection -> java.util.AbstractCollection -> MutableCollection (mapped to java.util.Collection) -> Collection (also mapped to java.util.Collection). But the source code of StdLib doesn't have some methods from java.util.Collection, e.g. kotlin.collections.Collection.stream(), although they can be called. Suggestion: filter out these methods.

But we have problems with anchor links.

1. E.g., A -> C, B -> C. method1 is in C, but it has the same DRI in A, B, C classes. anchorsIndex from DokkaLocationProvider knows nothing about which one (A,B or C) should be chosen.
2. For a method with external DRI (e.g. java.util.Collection.method()) Dokka have an anchor link to this method instead of an external link.

[IgnatBeresnev]

The problem is on our side in the place where internal links (anchor) are resolved.

Typealises have their own pages now, so the internal link resolution might not be needed anymore, and this issue might be fixed by removing this resolution.

The anchor link resolution is somewhat confusing, so it might take longer to fix.

[vmishenev]

Related issue: #3054