Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

the compiler version included in the idea plugin is not supported #57

Open
christophsturm opened this issue Feb 9, 2022 · 4 comments
Open

Comments

@christophsturm
Copy link
Contributor

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

image

@bnorm
Copy link
Owner

bnorm commented Feb 9, 2022

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.

@christophsturm
Copy link
Contributor Author

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

@bnorm
Copy link
Owner

bnorm commented Mar 13, 2022

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.

@TWiStErRob
Copy link
Contributor

TWiStErRob commented Mar 13, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants