the compiler version included in the idea plugin is not supported
christophsturm opened this issue · comments
everything works fine when building with gradle, but when i configure Idea to use its internal JPS build system (which is sometimes faster) it seems to use a different compiler version and that does not work with kotlin-power-assert: (idea plugin 213-1.6.10-release-944-IJ6461.79)
Kotlin: [Internal Error] java.lang.IllegalStateException: The provided plugin com.bnorm.power.PowerAssertComponentRegistrar is not compatible with this version of compiler
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.registerExtensionsFromPlugins$cli(KotlinCoreEnvironment.kt:675)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$ProjectEnvironment.registerExtensionsFromPlugins(KotlinCoreEnvironment.kt:169)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.<init>(KotlinCoreEnvironment.kt:216)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.<init>(KotlinCoreEnvironment.kt:111)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.createForProduction(KotlinCoreEnvironment.kt:485)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.createCoreEnvironment(K2JVMCompiler.kt:227)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:153)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:52)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:92)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:44)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:98)
at org.jetbrains.kotlin.daemon.CompileServiceImpl.compile(CompileServiceImpl.kt:1542)
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 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:712)
at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
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)
Caused by: java.lang.AbstractMethodError: Receiver class com.bnorm.power.PowerAssertComponentRegistrar does not define or inherit an implementation of the resolved method 'abstract void registerProjectComponents(com.intellij.mock.MockProject, org.jetbrains.kotlin.config.CompilerConfiguration)' of interface org.jetbrains.kotlin.compiler.plugin.ComponentRegistrar.
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.registerExtensionsFromPlugins$cli(KotlinCoreEnvironment.kt:667)
... 28 more
Also related to #38.
This is happening because the artifact generated for Gradle to use is must be built against the embedded Kotlin compiler dependency which shades the com.intellij.mock.MockProject
class. Looks like IntelliJ is also trying to use that artifact with the non-embedded compiler.
2 questions:
- Is this failing for any other 3rd-party compiler plugins that you have tried? Or is it just mine?
- Is this failing for any Kotlin supported compiler plugins? Like serialization or all-open for example.
If it's only failing for mine I could take a look at the other plugins you have tried and see if there is something I can adopt. In the meantime I'll poke around the Kotlin supported compiler plugins and see what they do.
serialization works, but i haven't tried with any other 3rd party plugin.
I also found this issue which describes the problem https://youtrack.jetbrains.com/issue/KT-25596
I don't think there is anything I can do here. Unless I could somehow override both abstract methods and call the right register function in them? I think I unfortunately have to just keep point people to https://youtrack.jetbrains.com/issue/KT-25596 and telling them it's an IntelliJ problem and to use Gradle to build and run inside IntelliJ instead.
@bnorm I have had success suppressing compile errors, but don't know if it would work in this case. So, I have a feeling you could theoretically put an override
on a function that doesn't exist in interfaces/supers. Each error message has a corresponding code that can be used in @Suppress("...")
.
Another alternative is creating an interface to force Kotlin accept the override method.
Actually, is it necessary to have it be an override
? Considering the call dispatch is trying to find it in the right place, would a simple function with the right signature suffice?
In case you need to compile against a non-existent class, you can create a stub module creating the signatures and No-op implementations. And then using it as compileOnly.