Different problem now: everything compiles fine on...
# compiler
r
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.
r
Could you please create an issue in YT with repro and short instruction
s
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 ;)
r
@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 🙂
👍 1
r
Yeah, I'll upload a sample project
👍 1
b
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.
r
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
r
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.
r
Yeah, although it worked fine on JVM without it
r
JVM doesn’t use klibs so it is not affected.