https://kotlinlang.org logo
Channels
Powered by
#multiplatform
Title
# multiplatform
s

serebit

07/25/2020, 8:46 PM
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.
i

ilya.gorbunov

07/27/2020, 3:05 AM
What is the compilation error in JVM?
s

serebit

07/27/2020, 3:14 AM
Let me grab it real quick...
Copy code
> 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
It's definitely imported, I have 
import kotlin.time.*
in the imports. Only if I directly import Monotonic does the code actually compile.
Oh, that's interesting. If I directly import TimeSource, it compiles, but it seems like the wildcard isn't catching it somehow.
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?
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.
i

ilya.gorbunov

07/27/2020, 3:33 AM
Kotlin can report unresolved reference also when there's an ambiguity. Can it be that you have several 
TimeSource
types/identifiers available in JVM?
s

serebit

07/27/2020, 4:38 AM
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.
i

ilya.gorbunov

07/30/2020, 4:20 AM
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
.
👍 1
s

serebit

07/30/2020, 4:22 AM
Thanks for taking care of the report! I'm surprised nobody else ran into this. 😆
2 Views
Powered by