I'm trying to get a library working with wasmJs, b...

# webassembly

[Nick]

I'm trying to get a library working with wasmJs, but am having issues when consuming it from an app module. The library compiles fine, and the JS version of the consuming app works as expected. But compilation of the wasmJs part of the app fails with the following error:

java.util.NoSuchElementException: Key CLASS CLASS name:Window modality:ABSTRACT visibility:internal [external] superTypes:[kotlin.Any] is missing in the map.
	at kotlin.collections.MapsKt__MapWithDefaultKt.getOrImplicitDefaultNullable(MapWithDefault.kt:24)
	at kotlin.collections.MapsKt__MapsKt.getValue(Maps.kt:360)
	at org.jetbrains.kotlin.backend.wasm.ir2wasm.WasmCompiledModuleFragment.linkWasmCompiledFragments(WasmCompiledModuleFragment.kt:132)
	at org.jetbrains.kotlin.backend.wasm.CompilerKt.compileWasm(compiler.kt:108)
	at org.jetbrains.kotlin.cli.js.K2JsIrCompiler.doExecute(K2JsIrCompiler.kt:361)
	at org.jetbrains.kotlin.cli.js.K2JSCompiler.doExecute(K2JSCompiler.java:181)
	at org.jetbrains.kotlin.cli.js.K2JSCompiler.doExecute(K2JSCompiler.java:72)
	at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:104)
	at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:48)
	at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:101)
	at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:79)
	at org.jetbrains.kotlin.cli.common.CLICompiler.execAndOutputXml(CLICompiler.kt:64)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.jetbrains.kotlin.compilerRunner.GradleKotlinCompilerWork.compileInProcessImpl(GradleKotlinCompilerWork.kt:396)
	at org.jetbrains.kotlin.compilerRunner.GradleKotlinCompilerWork.access$compileInProcessImpl(GradleKotlinCompilerWork.kt:80)
	at org.jetbrains.kotlin.compilerRunner.GradleKotlinCompilerWork$compileInProcess$future$1.call(GradleKotlinCompilerWork.kt:369)
	at org.jetbrains.kotlin.compilerRunner.GradleKotlinCompilerWork$compileInProcess$future$1.call(GradleKotlinCompilerWork.kt:368)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:833)

The class in question is defined in commonMain as:

internal expect abstract external class Window {
    // ...
}

And it has the following actual in a shared source-set inherited by jsMain and wasmJsMain

internal actual abstract external class Window {
    // ...
}

This works builds and runs fine when targeting JS. But compilation fails as I mentioned when including the wasmJs target in the app.

I stepped through the compilation a bit and can see that this class is listed in WasmCompiledModuleFragment.typeIds.unbound along w/ many other types. But the failure occurs because it is not located in the WasmCompiledModuleFragment.typeInfo.defined map.

I'd appreciate any help getting past this. 🙏

[Svyatoslav Kuzmich [JB]]

The error looks like a backend attempted to generate usages of this type, but without properly processing the definition. This should not happen, and unfortunately the error message doesn’t give enough information to understand why. Could you share source code that can reproduce this crash?

[Nick]

Let me see if I get a minimum required bit of code to repro. Thanks for following up.

[Nick]

I was able to reproduce it with this repro narrow setup. The issue is related to using Kodein with a type that's defined externally. I haven't dug beyond that, but wonder if it's related to inline functions and generics.

[Svyatoslav Kuzmich [JB]]

Thanks! I was able to reproduce it, made a one-button reproduction .zip and filed it to https://youtrack.jetbrains.com/issue/KT-64890/K-Wasm-compiler-crash-with-external-class-and-Kodein

I’ll try to see what is causing this, and if there is a workaround for now.

[Svyatoslav Kuzmich [JB]]

There is a bug with using typeOf (used internally by Kodein) with external class . The best workaround I see is to avoid using external classes with Kodein for now.

[bashor]

@Nick did you found workaround for the issue or are you blocked?

[Nick]

i worked around it by not having the external types resolved by Kodein’s injector. thanks for following up.

[Luca]

Any chance this will be fixed in the next release? I would like a to get a Kamel build out supporting wasm, but I’m blocked by this @bashor

[bashor]

@Luca work on a fix is in-progress, feel free to vote & follow KT-64890

[Luca]

Yup, I reported the related issue tagged there as well 👍. I'll keep watching