[K2] Fix order of KDoc link candidates #3447
Conversation
| private var linkCandidatesComparator: Comparator<KtSymbol> = compareBy{ | ||
| when(it) { | ||
| is KtClassifierSymbol -> 1 | ||
| is KtPackageSymbol -> 2 | ||
| is KtFunctionSymbol -> 3 | ||
| is KtVariableSymbol-> 4 | ||
| else -> 5 | ||
| } | ||
| } |
There was a problem hiding this comment.
Could you please cover all cases with tests? I see a test for the initial bug where class < function, which is good, and it would be very helpful to make sure other cases don't break either. Especially once KT-64190 is fixed - it will help us verify that it was implemented the way we expected
And a side question: can there be two symbols of the same type? For example, two KtClassifierSymbol? Asking in case there's a non-obvious corner case related to source sets, expect/actual, internal visibility, java interop or something else? If there is, does it make sense to add a second comparison like thenBy { it.name } (but with something that's different between the two), to make it predictable?
There was a problem hiding this comment.
can there be two symbols of the same type?
It is possible for KtFunctionSymbol when there are overloads. In this case, the order is not specified at all and it does not affect a result URL. It is not easy to make the order like in K1 on Dokka's side and consistent with IDEA. See added tests for overloads
For the other types of symbols, it is difficult to come up with a case when we have the same name in the same scope.
There was a problem hiding this comment.
I think a stable order of overloads can be addressed in #3250
0014f03 to
cf89e6a
Compare
cf89e6a to
a645424
Compare
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
Fixes #3375