Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[K2] Fix order of KDoc link candidates #3447

Merged
merged 3 commits into from
Jan 25, 2024

Conversation

vmishenev
Copy link
Member

Fixes #3375

@vmishenev vmishenev marked this pull request as ready for review January 15, 2024 10:18
Comment on lines +89 to +97
private var linkCandidatesComparator: Comparator<KtSymbol> = compareBy{
when(it) {
is KtClassifierSymbol -> 1
is KtPackageSymbol -> 2
is KtFunctionSymbol -> 3
is KtVariableSymbol-> 4
else -> 5
}
}
Copy link
Member

@IgnatBeresnev IgnatBeresnev Jan 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a stable order of overloads can be addressed in #3250

@vmishenev vmishenev force-pushed the vmishenev/3375-fix-order-of-kdoc-link-candidates branch 5 times, most recently from 0014f03 to cf89e6a Compare January 19, 2024 09:41
@vmishenev vmishenev force-pushed the vmishenev/3375-fix-order-of-kdoc-link-candidates branch from cf89e6a to a645424 Compare January 25, 2024 14:27
@vmishenev vmishenev merged commit 671e856 into master Jan 25, 2024
11 of 12 checks passed
@vmishenev vmishenev deleted the vmishenev/3375-fix-order-of-kdoc-link-candidates branch January 25, 2024 16:08
Luqman2302

This comment was marked as abuse.

@Kotlin Kotlin deleted a comment from Luqman2302 Jan 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[K2] List reference leads to the stdlib collections package
4 participants