Can FileSystem.SYSTEM be used in a single JVM + Native source set with HMPP?

[petertrr]

I am developing an app for JVM, LinuxX64, MingwX64 and MacosX64 targets. I am trying to place common logic in a common source set for all four targets like this (Okio 3.1.0, Kotlin 1.6.21 with HMPP enabled, Gradle 7.4.2):

plugins {
    kotlin("multiplatform") version "1.6.21"
}

repositories {
    mavenCentral()
}

kotlin {
    jvm()
    val nativeTargets = listOf(linuxX64(), mingwX64(), macosX64())

    sourceSets {
        val commonMain by getting
        val commonTest by getting
        val commonNonJsMain by creating {
            dependsOn(commonMain)
            dependencies {
                api("com.squareup.okio:okio:3.1.0")
            }
        }
        val commonNonJsTest by creating {
            dependsOn(commonTest)
            dependencies {
                implementation(kotlin("test-common"))
                implementation(kotlin("test-annotations-common"))
            }
        }
        val jvmMain by getting {
            dependsOn(commonNonJsMain)
        }
        val jvmTest by getting {
            dependsOn(commonNonJsTest)
            dependencies {
                implementation(kotlin("test-junit5"))
                implementation("org.junit.jupiter:junit-jupiter-engine:5.8.2")
            }
        }
        nativeTargets.forEach {
            getByName("${it.name}Main").dependsOn(commonNonJsMain)
        }
        nativeTargets.forEach {
            getByName("${it.name}Test").dependsOn(commonNonJsTest)
        }
    }
}

and then use this source set like this: src/commonNonJsMain/kotlin/org/example/Main.kt:

package org.example

import okio.FileSystem

val fs = FileSystem.SYSTEM

However, this code doesn't compile. This can be fixed by adding expect val FileSystem.SYSTEM in commonNonJsMain and adding actual declarations in just two source sets: jvmMain and nativeMain. Is it supposed to be working like this or am I doing something wrong? I suspect that the reason may be that there is no expect val SYSTEM in any high-level source set in Okio; FileSystem.SYSTEM just appears in some of target source sets, unlike e.g. runBlocking in this example.

Also, disabling HMPP by adding kotlin.mpp.hierarchicalStructureSupport=false in gradle.properties makes this example compile, even though symbols are still unresolved in IDEA.

[swankjesse]

It works for me on Kotlin 1.6.21 at the command line. In IntelliJ the symbol doesn’t resolve. I consider this to be a bug in IntelliJ.

[swankjesse]

But looking into how the symbols are represented, I think I can probably prevent this warning by creating a nonJsMain target that declares an expect for this symbol.

[petertrr]

Hey, thanks for your reply! I've created a reproducer repo (should've done it earlier 😅) at https://github.com/petertrr/okio-reproducer-1115. I've also included a Github Actions workflow to build the code, and it still fails with the same error:

e: /home/runner/work/okio-reproducer-1115/okio-reproducer-1115/src/commonNonJsMain/kotlin/org/example/Main.kt: (5, 21): Unresolved reference: SYSTEM

> Task :compileCommonNonJsMainKotlinMetadata FAILED

[swankjesse]

Ahh, I see the difference. It works in a project with no JS; it doesn't work in a non-JS source set.

Either way I expect we can fix it in Okio with more expect declarations.

[avenwu]

When using v3.1.0, reference to FileSystem.SYSTEM inside common source will fail the compiler. Define a custom actual/expect to use FileSystem can avoid the error before new version was shipped.😅

internal expect fun defaultFileSystem(): FileSystem

internal actual fun defaultFileSystem(): FileSystem {
    return FileSystem.SYSTEM
}