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

DClass.companion and DClass.classlikes.single() are different #4022

Open
owengray-google opened this issue Feb 7, 2025 · 0 comments
Open
Labels

Comments

@owengray-google
Copy link
Contributor

owengray-google commented Feb 7, 2025

If you investigate the documentable model for a class with a companion object, DClass.companion and DClass.classlikes.single() are different by reference. They represent the same object, and have the the same values in every field, recursively.

However, they are also different by value, because .equals() on the data class DClass recurses into DClass.sources.values.single().descriptor.equals(), which is (in K1) a non-data-class org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassDescriptor which compares by reference instead of by value. I would guess that the K2 implementation of DocumentableSource similarly recurses into a problematic upstream object.

a) Please make sure that only one DObject is created for each companion object. Not only should this (slightly) help performance, it will help avoid running into issues like this when trying to check if a companion object is contained within a list of objects.
b) Please make Documentables compare by value correctly. Avoiding sources entirely in an overridden .equals()/.hashCode would maintain correctness IMO, but making the upstream objects inside all implementations of DocumentableSources compare by value would probably be more correct, though skipping them in .equals()/.hashCode implementations probably can be made correct.

jaavid pushed a commit to J-Androids/superproject that referenced this issue Feb 10, 2025
Due to Kotlin/dokka#4022, we can only use
either .classlikes or .companion in dackka, and .companion cannot
address all of our use cases.

Test: internal refactor, no effect/test diff means success
Change-Id: I7c0039b6c039f87453859b816160544905871a7d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant