Good afternoon all! We decided to run our benchmar...

# k2-adopters

[dniHze]

Good afternoon all! We decided to run our benchmark against Beta4 (wanted to try k2 kapt too), and we faced some difficulties compiling modules (that were compiling perfectly fine with Beta1 and stable). I've created [an issue](https://youtrack.jetbrains.com/issue/KT-66148/K2-FileAnalysisException-in-Beta4) on YouTrack, but I wonder if someone might have an idea what it might be caused by? The code doesn't look suspicious at all. Code snipper is available in the ticket.

Exception:

e: org.jetbrains.kotlin.util.FileAnalysisException: While analysing /Users/a.dorosh/StudioProjects/*******/MviBaseDsl.kt:58:21: java.lang.IllegalArgumentException: Failed requirement.
        at org.jetbrains.kotlin.util.AnalysisExceptionsKt.wrapIntoFileAnalysisExceptionIfNeeded(AnalysisExceptions.kt:56)
        at org.jetbrains.kotlin.fir.FirCliExceptionHandler.handleExceptionOnFileAnalysis(Utils.kt:180)
        at org.jetbrains.kotlin.fir.resolve.transformers.body.resolve.FirDeclarationsResolveTransformer.transformFile(FirDeclarationsResolveTransformer.kt:1575)
        at org.jetbrains.kotlin.fir.resolve.transformers.body.resolve.FirAbstractBodyResolveTransformerDispatcher.transformFile(FirAbstractBodyResolveTransformerDispatcher.kt:57)
        at org.jetbrains.kotlin.fir.resolve.transformers.body.resolve.FirAbstractBodyResolveTransformerDispatcher.transformFile(FirAbstractBodyResolveTransformerDispatcher.kt:24)
        at org.jetbrains.kotlin.fir.declarations.FirFile.transform(FirFile.kt:48)
        ***

[kirillrakhman]

Do you have some implicit this access in your code?

[dmitriy.novozhilov]

It seems that the reason is builder inference
@dniHze could you please provide an information I asked in the ticket?

[dniHze]

Hey @dmitriy.novozhilov, tried to add all details requested. Let me know if anything else might be needed to identify the root cause.

[dniHze]

Hey @kirillrakhman, innerTransformation() is a function, scoped to the same class as onBinding() . I believe this qualifies as an implicit this call.

[dmitriy.novozhilov]

As a workaround you can add explicit type arguments to binding call
I believe it would be binding<String, Unit> {...}, but I may be mistaken

[dniHze]

Indeed, adding explicit type arguments to this call no longer hinders the compiler. We can unlock our benchmarks for now, thanks!

[dniHze]

(unrelated to the main thread topic) We also tried K2 KAPT, and we encountered some difficulties. Still works well in compat mode, but fails in K2 mode. More details here: https://youtrack.jetbrains.com/issue/KT-66207/K2-w-kapt-JvmSuppressWildcards-is-not-properly-applied-to-generated-stubs

[dniHze]

Btw, it looks like metadata format was updated in the K2 KAPT? I've managed to rule out the above issue by just applying @JvmSuppressWildcards to type arguments instead of the collection, but Dagger now fails with NPE when tries to access the metadata here. They are using org.jetbrains.kotlinx:kotlinx-metadata-jvm:0.9.0. Is that a bug or intended behaviour, as the kotlinx-metadata-jvm artefact may require an update to process thing properly?

[dmitriy.novozhilov]

cc @Ilmir Usmanov [JB]