Kotlin NoSuchMethodError when running with type resolution on Kotlin 1.8.0-Beta

[orrc]

Expected Behavior

Running the detektMain Gradle task should complete without failures.

Observed Behavior

A build with detektMain works fine with Kotlin 1.7.21, but fails with Kotlin 1.8.0-Beta.
Using the detekt task works fine with both.

Works with Kotlin 1.7.21:

$ gw --no-daemon --no-build-cache --console plain --stacktrace clean detektMain
…
> Task :modules:app:clean
> Task :modules:list:clean
> Task :modules:utilities:clean
> Task :modules:list:processResources NO-SOURCE
> Task :modules:utilities:processResources NO-SOURCE
> Task :modules:list:compileKotlin
> Task :modules:list:compileJava NO-SOURCE
> Task :modules:list:classes UP-TO-DATE
> Task :modules:list:jar
> Task :modules:list:inspectClassesForKotlinIC
> Task :modules:utilities:compileKotlin
> Task :modules:utilities:compileJava NO-SOURCE
> Task :modules:utilities:classes UP-TO-DATE
> Task :modules:utilities:jar
> Task :modules:utilities:inspectClassesForKotlinIC
> Task :modules:utilities:detektMain
> Task :modules:list:detektMain
> Task :modules:app:detektMain

BUILD SUCCESSFUL in 4s
12 actionable tasks: 12 executed

Fails with Kotlin 1.8.0-Beta:

$ gw --no-daemon --no-build-cache --console plain --stacktrace clean detektMain
…
> Task :modules:app:clean
> Task :modules:list:clean
> Task :modules:utilities:clean
> Task :modules:utilities:processResources NO-SOURCE
> Task :modules:list:processResources NO-SOURCE
> Task :modules:list:compileKotlin
> Task :modules:list:compileJava NO-SOURCE
> Task :modules:list:classes UP-TO-DATE
> Task :modules:list:jar
> Task :modules:list:inspectClassesForKotlinIC
> Task :modules:utilities:compileKotlin
> Task :modules:utilities:compileJava NO-SOURCE
> Task :modules:utilities:classes UP-TO-DATE
> Task :modules:utilities:jar
> Task :modules:utilities:inspectClassesForKotlinIC
> Task :modules:utilities:detektMain
> Task :modules:list:detektMain
> Task :modules:app:detektMain FAILED
…

Caused by: org.gradle.api.GradleException: java.lang.IllegalStateException: Analyzing /Users/chris/code/project/modules/app/src/main/kotlin/com/example/app/App.kt led to an exception.
Location: java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315)
The original exception message was: java.lang.NoSuchMethodError: 'boolean org.jetbrains.kotlin.resolve.bindingContextUtil.BindingContextUtilsKt.isUsedAsExpression(org.jetbrains.kotlin.psi.KtExpression, org.jetbrains.kotlin.resolve.BindingContext
)'
Running detekt '1.22.0' on Java '17.0.5+8-LTS' on OS 'Mac OS X'
If the exception message does not help, please feel free to create an issue on our GitHub page.
        at io.gitlab.arturbosch.detekt.invoke.DefaultCliInvoker.invokeCli(DetektInvoker.kt:64)
        at io.gitlab.arturbosch.detekt.Detekt.check(Detekt.kt:253)
        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 org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:125)
        …
Caused by: java.util.concurrent.CompletionException: java.lang.NoSuchMethodError: 'boolean org.jetbrains.kotlin.resolve.bindingContextUtil.BindingContextUtilsKt.isUsedAsExpression(org.jetbrains.kotlin.psi.KtExpression, org.jetbrains.kotlin.resol
ve.BindingContext)'
Caused by: java.lang.NoSuchMethodError: 'boolean org.jetbrains.kotlin.resolve.bindingContextUtil.BindingContextUtilsKt.isUsedAsExpression(org.jetbrains.kotlin.psi.KtExpression, org.jetbrains.kotlin.resolve.BindingContext)'
        at io.gitlab.arturbosch.detekt.rules.bugs.IgnoredReturnValue.visitCallExpression(IgnoredReturnValue.kt:98)
        at org.jetbrains.kotlin.psi.KtVisitorVoid.visitCallExpression(KtVisitorVoid.java:811)
        at org.jetbrains.kotlin.psi.KtVisitorVoid.visitCallExpression(KtVisitorVoid.java:21)
        at org.jetbrains.kotlin.psi.KtCallExpression.accept(KtCallExpression.java:35)
        at org.jetbrains.kotlin.psi.KtElementImpl.accept(KtElementImpl.java:51)
        at org.jetbrains.kotlin.com.intellij.psi.impl.source.tree.LazyParseablePsiElement.acceptChildren(LazyParseablePsiElement.java:104)
        …

Steps to Reproduce

I tried to reproduce this from scratch with a couple of tiny projects created using gradle init, and added a method that triggered IgnoredReturnValue when running detektMain, but I unfortunately couldn't reproduce this failure with Kotlin 1.8.0-Beta.

However, hopefully someone has an idea of what the underlying cause might be here. Otherwise, I can try and reduce the existing project above down to something simpler and reproducible.

Context

I'm trying to use type resolution to get more thorough static analysis, but falling back to "regular" Detekt also isn't a huge deal.

Your Environment

• Version of detekt used: 0.22.0
• Version of detekt-gradle-plugin used: 1.22.0
• Version of Gradle used: 7.6
• Operating System and version: macOS 12.6 (M1)
• JDK: OpenJDK 64-Bit Server VM Zulu17.38+21-CA (build 17.0.5+8-LTS, mixed mode, sharing)

[3flex]

Please have a look at #5551 - I suspect the same root cause.

[BraisGabin]

This issues are more and more frequent... should our gradle plugin check for the version of the compiler that is in the classpath and fail with a descriptive message? It's not just to avoid the "noise" on the issue tracker (I'm not too much converned there) but to give a fast feedback to out users.

[3flex]

It should, yes, but when I tried implementing a check it wasn't all that clean and I wasn't confident that it would be reliable. If someone wants to pick that up then please go ahead.

[DanySK]

I think that I might have hit this here: https://scans.gradle.com/s/2xqkokxu3nanc/failure#1

[3flex]

Yes, if you look at the Dependencies in the build scan, and drill down into the detekt configuration, you'll see the dependency version has been overridden.

I'm going to close this, as there's a new issue to cover adding a warning, and this appears to be a support issue and not an issue with detekt itself.