is 2.1.20-RC working for you? Just trying to figur...
# javascript
b
is 2.1.20-RC working for you? Just trying to figure out if I've missed a breaking change, but code that compiles fine in 2.1.10 gives me a
Copy code
java.lang.AssertionError: Different declarations with the same signatures were detected, but no diagnostics will be reported because none of those declarations have any source location info associated with them. This could happen because the declarations came from an external module, or were generated by a compiler plugin. The following declarations have conflicting signatures:
 - FUN GENERATED[org.jetbrains.kotlinx.jspo.compiler.resolve.JsPlainObjectsPluginKey] name:invoke visibility:public modality:FINAL <> (actorUuid:kotlin.String, favoriteMeal:kotlin.String?, chosenMeal:kotlin.String) returnType:at.posselt.pfrpg2e.camping.ActorMeal [inline,operator]
 - FUN GENERATED[org.jetbrains.kotlinx.jspo.compiler.resolve.JsPlainObjectsPluginKey] name:invoke visibility:public modality:FINAL <> (recipeName:kotlin.String, result:kotlin.String?, skill:kotlin.String) returnType:at.posselt.pfrpg2e.camping.CookingResult [inline,operator]

	at org.jetbrains.kotlin.ir.linkage.SignatureClashDetector.reportSignatureClashTo(SignatureClashDetector.kt:71)
	at org.jetbrains.kotlin.backend.common.diagnostics.IdSignatureClashDetector.reportSignatureConflict(IdSignatureClashDetector.kt:21)
	at org.jetbrains.kotlin.backend.common.diagnostics.IdSignatureClashDetector.reportSignatureConflict(IdSignatureClashDetector.kt:15)
	at org.jetbrains.kotlin.ir.linkage.SignatureClashDetector.reportErrorsTo(SignatureClashDetector.kt:53)
	at org.jetbrains.kotlin.backend.common.serialization.IrModuleSerializer.serializedIrModule(IrModuleSerializer.kt:43)
	at org.jetbrains.kotlin.backend.common.serialization.SerializeModuleIntoKlibKt.serializeModuleIntoKlib(serializeModuleIntoKlib.kt:154)
	at org.jetbrains.kotlin.ir.backend.js.KlibKt.serializeModuleIntoKlib(klib.kt:587)
	at org.jetbrains.kotlin.cli.pipeline.web.WebKlibSerializationPipelinePhase.serializeFirKlib(WebKlibSerializationPipelinePhase.kt:116)
	at org.jetbrains.kotlin.cli.pipeline.web.WebKlibSerializationPipelinePhase.executePhase(WebKlibSerializationPipelinePhase.kt:48)
	at org.jetbrains.kotlin.cli.pipeline.web.WebKlibSerializationPipelinePhase.executePhase(WebKlibSerializationPipelinePhase.kt:27)
	at org.jetbrains.kotlin.cli.pipeline.PipelinePhase.phaseBody(PipelinePhase.kt:68)
	at org.jetbrains.kotlin.cli.pipeline.PipelinePhase.phaseBody(PipelinePhase.kt:58)
	at org.jetbrains.kotlin.config.phaser.SimpleNamedCompilerPhase.phaseBody(CompilerPhase.kt:215)
	at org.jetbrains.kotlin.config.phaser.NamedCompilerPhase.invoke(CompilerPhase.kt:111)
	at org.jetbrains.kotlin.backend.common.phaser.CompositePhase.invoke(PhaseBuilders.kt:28)
	at org.jetbrains.kotlin.config.phaser.CompilerPhaseKt.invokeToplevel(CompilerPhase.kt:62)
	at org.jetbrains.kotlin.cli.pipeline.AbstractCliPipeline.runPhasedPipeline(AbstractCliPipeline.kt:106)
	at org.jetbrains.kotlin.cli.pipeline.AbstractCliPipeline.execute(AbstractCliPipeline.kt:65)
	at org.jetbrains.kotlin.cli.js.K2JSCompiler.doExecutePhased(K2JSCompiler.kt:63)
	at org.jetbrains.kotlin.cli.js.K2JSCompiler.doExecutePhased(K2JSCompiler.kt:49)
	at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:80)
	at org.jetbrains.kotlin.cli.common.CLICompiler.exec(CLICompiler.kt:337)
	at org.jetbrains.kotlin.incremental.IncrementalJsCompilerRunner.runCompiler(IncrementalJsCompilerRunner.kt:199)
	at org.jetbrains.kotlin.incremental.IncrementalJsCompilerRunner.runCompiler(IncrementalJsCompilerRunner.kt:74)
	at org.jetbrains.kotlin.incremental.IncrementalCompilerRunner.doCompile(IncrementalCompilerRunner.kt:514)
	at org.jetbrains.kotlin.incremental.IncrementalCompilerRunner.compileImpl(IncrementalCompilerRunner.kt:431)
	at org.jetbrains.kotlin.incremental.IncrementalCompilerRunner.compileNonIncrementally(IncrementalCompilerRunner.kt:310)
	at org.jetbrains.kotlin.incremental.IncrementalCompilerRunner.compile(IncrementalCompilerRunner.kt:137)
	at org.jetbrains.kotlin.incremental.IncrementalCompilerRunner.compile$default(IncrementalCompilerRunner.kt:117)
	at org.jetbrains.kotlin.daemon.CompileServiceImplBase.execJsIncrementalCompiler(CompileServiceImpl.kt:612)
	at org.jetbrains.kotlin.daemon.CompileServiceImplBase.access$execJsIncrementalCompiler(CompileServiceImpl.kt:92)
	at org.jetbrains.kotlin.daemon.CompileServiceImpl.compile(CompileServiceImpl.kt:1903)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:360)
	at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
	at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:714)
	at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:598)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:844)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:721)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:720)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1583)
1
looks like it's a bug, can reproduce it and will post a bug report
sorry for the ping artem
a
It's a bug. We've already fixed it for 2.2.0. I will do all the needed work to port it into 2.1.20 release
b
ah, thank you, then I'll refrain from opening an issue
a
Thank you for pinging me 🙏 We've already created an issue (I will send it in a few minutes)
b
As a temporary workaround, you can move one of your
@JsPlainObject
-annotated interfaces to a different package.
b
I've also noticed btw that private JsPlainObjects clash if they are defined in the same package but a different file; but I suppose this is to be expected?
can't remember anymore if private means package or file private
b
Do you get a similar exception in that case?
b
no, just a Redeclaration error
at least the docs say: If you mark a declaration as
private
, it will only be visible inside the file that contains the declaration.
so it looks like it should be file private
b
Do the files have the same name?
b
no
🤔 1
nvm, I suppose that's expected behavior
e
just a Redeclaration error
One comment on SO says
Seems like this makes
private
kind of useless, since it's effectively
internal
. I ran into this when trying to create a file-scoped helper class
In this case I tend to agree with it. I would have expected a transparent name change, but that's not only a K/JS issue