[K2] KMP: Support intersecting source roots

[atyrin]

Sometimes projects may use the same folder as source root in different modules. Like the same dir for several targets in KMP.
It can be done with such syntax:

kotlin {
  sourceSets {
    jsMain {
      kotlin.srcDir('src/browserMain/kotlin')
    }
    wasmJsMain {
      kotlin.srcDir('src/browserMain/kotlin')
    }
  }
}

Possible scenarios for that: Android and JVM source sets or Js and WasmJs. Sharing source sources for them using KMP hierarchies is just painful.

Projects that already use the pattern:

• https://github.com/cashapp/molecule/blob/34e57f70b1f7e7b08e9cd2ce6923e2f2b3be54b9/molecule-runtime/build.gradle#L77
• https://github.com/JakeWharton/mosaic/blob/eb76d4c1baf4605614f2346d081340c8d574320a/samples/counter/build.gradle#L18
• https://github.com/f-droid/fdroidclient/blob/d38b952e6dddef3d3baef9007e88d238e675be46/libs/download/build.gradle#L57
• https://github.com/GitLiveApp/firebase-kotlin-sdk/blob/1abbb9b64fb2c9e77aaee22f74a3fe9a2f548b7d/firebase-config/build.gradle.kts#L145

Kotlin with K2 works fine for them.
IJ with Kotlin K2 Analysis also works: it just uses one of the platforms for analysis. And report warning:

Path [/Users/Andrei.Tyrin/IdeaProjects/_external/molecule/molecule-runtime/src/browserMain/kotlin] of module [molecule.molecule-runtime.jsMain] was removed from modules [molecule.molecule-runtime.wasmJsMain]

Dokka at the same time has the special treatment for that (#3239):

Pre-generation validity check failed: Source sets 'android' and 'jvm' have the common source roots: /Users/Andrei.Tyrin/IdeaProjects/_gates/firebase-kotlin-sdk_mpp/firebase-config/src/androidMain/kotlin. Every Kotlin source file should belong to only one source set (module).

---

There is a ticket to forbid such setup in KGP: https://youtrack.jetbrains.com/issue/KT-62829/Add-a-check-that-two-source-sets-cannot-have-the-same-file-system-directory. But the priority is low.

[vmishenev]

Related: #3373

[vmishenev]

There are 3 solutions here:

1. Support it on AA's side, e.g. https://youtrack.jetbrains.com/issue/IJPL-339/Multi-context-resolve-support-in-IJ-platform
2. Forbid such setup in KGP - https://youtrack.jetbrains.com/issue/KT-62829/Add-a-check-that-two-source-sets-cannot-have-the-same-file-system-directory
3. Add a workaround on Dokka's side

Workarounds:

1. Clone Documentable for common files
   For example,

   sourceSetA {  1.kt, 2.kt; platform: JVM; libsA}
   sourceSetB {  1.kt, 2.kt; platform: Android; libsB}
   

   can be mapped to the following project structure of AA:

   sourceSetA {  1.kt, 2.kt; platform: JVM; libsA}
   sourceSetB {  1.kt; platform: Android; libsB}
   

   2.kt should passed twice in the documentable translator.
   Pros:

   • Relative simplicity of implementation

   Cons:

   • Quite spread logic. It requires changes in the documentable translator and the session builder

2. Fake sourcesets
   The above-mentioned example can be mapped into:

   sourceSetA {  1.kt,  platform: JVM; libsA}
   sourceSetB {  1.kt; platform: Android; libsB}
   sourceSetAB {  2.kt; platform: JVM???; libsA}
   
   sourceSetA, sourceSetB depends on sourceSetAB (friend dependency)
   

   Disadvantages:

   • The target platform of a fake source set is under question: common can be insufficient. A different platform in a dependent source set can be unsupported(???) (or might be in the future).

3. Independent AA sessions
   Create an AA session for each source set or only for intersecting source sets.

   Pros:

   • The same symbol can be resolved into different types depending on the platform (is there a real case?)

   Cons:

   • Works only for independent source sets that do not depend on each other
   • Currently, an AA session is resource-consuming

[whyoleg]

Action point:

• add logging when running into this situation to create an issue on Dokka GitHub

[vmishenev]

Current tatus: We are awaiting feedback from Dokka 2.0.0.

[sureshg]

Dokka 2.0 task is failing (configuration cache enabled) when we have a custom hierarchy templates

 applyDefaultHierarchyTemplate {
    common {
      group("posix") {
        // Using group will add the intermediate source sets
        group("linux")
        group("apple")
      }

      group("jsCommon") {
        withJs()
        withWasmJs()
      }
    }
  }

t/kotlin. Every Kotlin source file should belong to only one source set (module).
     Also, please consider reporting your user case: https://github.com/Kotlin/dokka/issues/3701,Source sets 'jsCommon' and 'js' have the common sample roots: ../web/src/test/kotlin. Every Kotlin source file should belong to only one source set (module).
     Also, please consider reporting your user case: https://github.com/Kotlin/dokka/issues/3701,Source sets 'jsCommon' and 'wasmJs' have the common sample roots: ...web/src/test/kotlin. Every Kotlin source file should belong to only one source set (module).
     Also, please consider reporting your user case: https://github.com/Kotlin/dokka/issues/3701,Source sets 'js' and 'wasmJs' have the common sample roots:.../web/src/test/kotlin. Every Kotlin source file should belong to only one source set (module).
     Also, please consider reporting your user case: https://github.com/Kotlin/dokka/issues/3701

Even common dependencies between modules in a multi module kotlin multiplatform projects fails (Here jvm and wasjs modules depend on common)

    Also, please consider reporting your user case: https://github.com/Kotlin/dokka/issues/3701,Source sets 'common' and 'jvm' have the common sample roots:../shared/src/test/kotlin. Every Kotlin source file should belong to only one source set (module).
     Also, please consider reporting your user case: https://github.com/Kotlin/dokka/issues/3701,Source sets 'common' and 'wasmJs' have the common sample roots:.. shared/src/test/kotlin. Every Kotlin source file should belong to only one source set (module).

[whyoleg]

Dokka 2.0 task is failing (configuration cache enabled) when we have a custom hierarchy templates

Hey! is it possible to provide a reproducer (GitHub repo or zip)?
As message says have the common sample roots, most likely you provide the same sources root for different source sets in samples.
Do you think it's possible at your side to change it, so that there will be no intersected source sets ?(e.g like in this change)