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

# compiler

[rnett]

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.

[Roman Artemev [JB]]

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

[shikasd]

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 ;)

[Roman Artemev [JB]]

@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 🙂

[rnett]

Yeah, I'll upload a sample project

[bnorm]

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.

[rnett]

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

[rnett]

https://youtrack.jetbrains.com/issue/KT-42073

[Roman Artemev [JB]]

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.

[rnett]

Yeah, although it worked fine on JVM without it

[Roman Artemev [JB]]

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