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

kotlin 1.4.30: PowerAssertComponentRegistrar is not compatible with this version of compiler #38

Open
dkandalov opened this issue Mar 28, 2021 · 5 comments

Comments

@dkandalov
Copy link

plugins {
    id 'org.jetbrains.kotlin.jvm' version '1.4.30'
    id("com.bnorm.power.kotlin-power-assert") version "0.7.0"
}

produces this on compilation

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:574)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$ProjectEnvironment.registerExtensionsFromPlugins(KotlinCoreEnvironment.kt:129)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.<init>(KotlinCoreEnvironment.kt:169)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.<init>(KotlinCoreEnvironment.kt:109)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.createForProduction(KotlinCoreEnvironment.kt:421)
	at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.createCoreEnvironment(K2JVMCompiler.kt:226)
	at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:152)
	at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:52)
	at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:88)
	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:1485)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
	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(Native Method)
	at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:676)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)
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:566)
	... 28 more

@bnorm
Copy link
Owner

bnorm commented Mar 29, 2021

Something very strange is happening. The exception is reporting that PowerAssertComponentRegistrar doesn't override a function with the signature of registerProjectComponents(com.intellij.mock.MockProject, org.jetbrains.kotlin.config.CompilerConfiguration). However, the ComponentRegistrar class defines a function with the following signature: registerProjectComponents(org.jetbrains.kotlin.com.intellij.mock.MockProject, org.jetbrains.kotlin.config.CompilerConfiguration). Somehow, the project parameter is changing type.

Do you have any more detail about this project you can share? The sample directory of this project defines the same plugin versions and isn't reporting any issues.

@TWiStErRob
Copy link
Contributor

Could it be Gradle version with embedded Kotlin discrepancy?

@bnorm
Copy link
Owner

bnorm commented Mar 30, 2021

I sort of expect the problem to be the opposite. Kotlin/JVM and Kotlin/JS use the embedded compiler and Kotlin/Native uses the non-embedded compiler which is why there are 2 different artifacts. It appears here the non-embedded compiler is being used with a plugin compiled against the embedded compiler.

@dkandalov
Copy link
Author

I looked into the issue and it seems to be related IntelliJ 🙄
In particular, power-assert works fine from command line, i.e. ./gradlew build is successful.
It only fails in IntelliJ with enabled Build Tools -> Gradle -> Build and run using IntelliJ IDEA and Build Tools -> Gradle -> Run tests using IntelliJ IDEA.

https://github.com/dkandalov/power-assert-fail

IntelliJ IDEA 2021.1 Beta (Ultimate Edition)
Build #IU-211.6693.14, built on March 25, 2021
Kotlin: 211-1.4.21-release-IJ6693.10

or

IntelliJ IDEA 2020.3.3 (Ultimate Edition)
Build #IU-203.7717.56, built on March 15, 2021
Kotlin: 203-1.5.0-M2-release-538-IJ7717.8

@mikehearn
Copy link

Well, the error is correct. You're compiling against the embedded compiler that has this difference, whereas some environments need the regular compiler, for example, anything that's not Gradle.

I fixed this by simply changing the dependency to the regular compiler and fixing the import line. Now it works.

Maybe you could load the right class using reflection so the JAR is usable with either compiler? As it seems, this is the only namespace difference that matters, for some reason.

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

4 participants