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
| * that correspond to multiple KMP platforms, then it is [Platform.common] | ||
| */ | ||
| data class DisplaySourceSet( | ||
| public data class DisplaySourceSet( |
There was a problem hiding this comment.
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.
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.
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
| * that correspond to multiple KMP platforms, then it is [Platform.common] | ||
| */ | ||
| data class DisplaySourceSet( | ||
| public data class DisplaySourceSet( |
There was a problem hiding this comment.
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
SelfRepresentingSingletonSetas harmfulDisplaySourceSet