We’re running into an issue where `kapt` does not ...

# kapt

[kevin.cianfarini]

We’re running into an issue where kapt does not seem to see sources in our commonMain sourceset when generating stubs for android after the upgrade to Kotlin 1.9.0. In Kotlin 1.8.22 stubs were generated for everything in the androidMain sourceset and the commonMain sourceset, but after upgrading to 1.9.0 we’re only seeing stubs generated for the androidMain sourceset.

Does anyone have any tips on how we might begin to debut this? How does kapt locate source files to generate stubs for?

[tapchicoma]

Usually they are the same as for related KotlinJvmCompile task. But since 1.9.0 manual sources configuration for KotlinJvmCompile task is not back-propagated to the generate stubs task.

Is it your case?

[kevin.cianfarini]

cc @Richard Leggett

[kevin.cianfarini]

Richard and I have created a minimal reproducer so maybe you could help us look at that? I am just now heading off on vacation sadly but I trust Rich to take it from here. In the meantime, do you have any reading resources about

But since 1.9.0 manual sources configuration for KotlinJvmCompile task is not back-propagated to the generate stubs task.

?

[tapchicoma]

Check Kotlin 1.9.0 what's new - there should be a section about it

[Richard Leggett]

Thanks @tapchicoma! Just been reading the changes re kapt and eager task generation. I noted that this only affects non-default configuration. We're not using the tasks API directly, but we are using this workaround to get kapt working in a KMM shared code module.

val androidMain by getting {
  dependencies {
    ...various dependencies...
    
    configurations.getByName("kapt").dependencies.add(
      DefaultExternalModuleDependency(
        "com.google.dagger",
        "hilt-compiler",
        libs.versions.hilt.get()
      )
    )
 }
}

Do you think this could be causing stub generation to fail for commonMain sources?

I'll try to create an absolute barebones reproducer pending this, since the current one is still a module within the main codebase.

[tapchicoma]

hm, doubt that this code affects. Please try to create a repro project and open a new YouTrack Kotlin issue with it

[Richard Leggett]

Sounds like a plan thanks Yahor.

[Richard Leggett]

Just to update, we tried out Dagger/Hilt 2.48 via KSP and the issue persists so I guess it's not a kapt thing.

This is out of scope for this channel but to add some more findings in case anyone is curious...

It's looking more like a Hilt issue. It's a KMP project and we share ViewModels across both Android and iOS, so they live in commonMain.

We annotate those viewmodels with @SharedViewModel. Which is type aliased to @HiltViewModel
on Android (and no-op on iOS) using expect/actual.

Until now this has worked well, but since upgrading to Kotlin 1.9 it looks like the annotation is ignored / none of these shared VMs' are found by HiltViewModelFactory. Only ViewModels defined/annotated in androidMain remain present.

[tapchicoma]

but since upgrading to Kotlin 1.9

Still sounds that some change in Kotlin may cause it

[Richard Leggett]

yeah that makes sense, so maybe before hilt gets involved

[Richard Leggett]

I'm trying to figure out what steps/tasks I can do to confirm where it breaks.

I can see in the APK the @HiltViewModel annotated classes are present, but they never make it into the map of VMs Hilt provides when calling hiltViewModel(). I need to figure out where that map of keys is actually generated.

[tapchicoma]

I still advice you to create a repro-project and new Kotlin issue with it

[tapchicoma]

such way we could investigate the cause

[Richard Leggett]

We created a repro/standalone but it didn't have the problem 😄 so it's probably something somewhere else in the project. Will keep digging and try to get this.

[Richard Leggett]

Thanks again for your help. I've gone and added an issue/reproducer. https://youtrack.jetbrains.com/issue/KT-61622/Upgrading-to-Kotlin-1.9-prevents-commonMai[…]eset-classes-from-being-processed-by-kapt-ksp-dagger-Hilt

[tapchicoma]

Hi, finally got time to investigate it and this is a regression. Will try to add a fix into 1.9.20-RC release. Proposed workaround is correct until this issue is fixed

[kevin.cianfarini]

Thank you!!

[Richard Leggett]

Thank you very much!