-
Notifications
You must be signed in to change notification settings - Fork 407
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
Refactor and document DisplaySourceSet #3105
Conversation
…ing harmful and unimplement it in DisplaySourceSet * Provide no automatic migration for DisplaySourceSet as there is no mechanisms for that. Manual migration is replacement of 'dss' to `setOf(dss)` where applicable * Introduce a convenience-member DefaultRenderer.buildContentNode to avoid wrapping DSS into set manually Fixes #2897
*/ | ||
data class DisplaySourceSet( | ||
public data class DisplaySourceSet( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO it is worth making all constructors internal
and leaving only DokkaSourceSet.toDisplaySourceSet
. The API already kind of dictates that, but I'm not sure how drastic this change will be
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am wondering about a case with multiple DokkaSourceSet
(when we really need the primary constructor and CompositeSourceSetID
). I found a such case only in tests and do not know about an external case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably worth figuring it out systematically. This one might be too strict, especially for 1.9.20
…ward Iterable<DisplaySourceSet>.computeSourceSetIds() * Refactor all the usages, save some allocations * Start caching CompositeSourceSetID properties to avoid excessive allocations
c20a1f3
to
116d63d
Compare
The integration test failure is related to pathsaver plugin in Knit -- I'll see if it's patchable locally |
Into the master because the update contains a workaround required for Dokka, see Kotlin/dokka#3105
Into the master because the update contains a workaround required for Dokka, see Kotlin/dokka#3105
Into the master because the update contains a workaround required for Dokka, see Kotlin/dokka#3105
I've patched the Knit, updated it in coroutines/serialization and checked it helps. Next step is to update the submodule |
Into the master because the update contains a workaround required for Dokka, see Kotlin/dokka#3105
…re the workaround is applied
*/ | ||
data class DisplaySourceSet( | ||
public data class DisplaySourceSet( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am wondering about a case with multiple DokkaSourceSet
(when we really need the primary constructor and CompositeSourceSetID
). I found a such case only in tests and do not know about an external case.
Into the master because the update contains a workaround required for Dokka, see Kotlin/dokka#3105
SelfRepresentingSingletonSet
as harmfulDisplaySourceSet