Different problem now: everything compiles fine on JVM, but when I try to use it on JS, I get

java.lang.IllegalStateException: Not found Idx for public kotlin.collections/mapOf|5848051883920634516[0]

from the IrLinker. I'm referencing and using

mapOf(vararg Pair<>)

which works fine on JVM. The

compileKotlinJs

task works fine, it's the

compileProductionExecutableKotlinJs

task that fails. It's happening on other methods to. Seems to be just top level functions. Is this a known bug? Poking around in debug in

KotlinIrLinker.IrDeserializerForFile

, while the referenced function (in this case,

to

) isn't in

reversedSignitureIndex

, it is in

fileLocalDeserializationState.reachableTopLevels

, so it is obviously being found somehow.

Could you please create an issue in YT with repro and short instruction

Hey, how do you reference those functions? Sometimes, if IR deserializer cannot find a function, the references could be a bit wrong. The signature you are seeing gets to reachableTopLevels through your reference, and then deserializer cannot find exact match for some reason. But anyways, it is worth creating an issue to make it a known bug ;)

@shikasd yes, it is. It looks like a bug and has to be fixed but first I would prefer figure what exactly wrong out. The best to start so is create an issue 🙂

Yeah, I'll upload a sample project

I ran into this a couple times and it had to do with the types used for the type parameters of the function. I was trying to use the types from the IrSimpleFunctionSymbol (something like

functionSymbol.owner.valueParameters[0]!!.type

) instead of building the IrType properly.

yeah, I'm just now playing with it to make a sample project, and found that if I explicitly specify the return type of

to

in

irCall

, it works

Yeah, specifying return type is kind of required because of in case of generic return type

fun <T> foo(): T

the actual return type is different from declaration’s one. So I think the solution here could be a bit friendly diagnostic.

Yeah, although it worked fine on JVM without it

JVM doesn’t use klibs so it is not affected.