Odd situation I had with some Kotlin 1.3.72 multiplatform code earlier: - Usage of `MonoClock` comp...

# multiplatform

[serebit]

Odd situation I had with some Kotlin 1.3.72 multiplatform code earlier:
- Usage of MonoClock compiles in both common and JVM
- Usage of Monotonic (imported directly from TimeSource) compiles in both common and JVM
- Usage of TimeSource.Monotonic compiles in common, but fails in JVM
All three scenarios were regarded as acceptable by the IntelliJ Kotlin plugin (version 1.4-M3), but the last one failed to compile regardless.

[ilya.gorbunov]

What is the compilation error in JVM?

[serebit]

Let me grab it real quick...

[serebit]

> Task :client:compileKotlinJvm FAILED
e: /home/serebit/Code/strife/client/src/commonMain/kotlin/internal/network/Heart.kt: (47, 21): Unresolved reference: TimeSource

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':client:compileKotlinJvm'.
> A failure occurred while executing org.jetbrains.kotlin.compilerRunner.GradleKotlinCompilerWork
   > Compilation error. See log for more details

[serebit]

It's definitely imported, I have import kotlin.time.* in the imports. Only if I directly import Monotonic does the code actually compile.

[serebit]

Oh, that's interesting. If I directly import TimeSource, it compiles, but it seems like the wildcard isn't catching it somehow.

[serebit]

Optimizing imports isn't getting rid of import kotlin.time.TimeSource either, even though it's got import kotlin.time.TimeSource directly above it. 🤔 What have I stumbled upon?

[serebit]

Okay. To summarize what I've found, because it appears to be a bit different upon looking into it.
When importing `kotlin.time.*`:
- Usage of MonoClock compiles in both common and JVM
- Usage of TimeSource compiles in common, but fails in JVM due to an unresolved reference
When importing TimeSource directly, it succeeds in both common and JVM. The Kotlin IDEA plugin doesn't see any issues either way.

[ilya.gorbunov]

Kotlin can report unresolved reference also when there's an ambiguity. Can it be that you have several TimeSource types/identifiers available in JVM?

[serebit]

Aha, yep! There's an internal TimeSource interface in kotlinx.coroutines. Perhaps that should be renamed to avoid conflicts with the new kotlin.time.TimeSource interface.

[ilya.gorbunov]

Thank you for reporting this, I've added this case to the issue: https://youtrack.jetbrains.com/issue/KT-23727#focus=Comments-27-4305968.0-0
Meanwhile, we're likely to rename the internal TimeSource in kotlinx.coroutines.

[serebit]

Thanks for taking care of the report! I'm surprised nobody else ran into this. 😆