Open freszu opened 2 years ago
bcorso
commented
2 years ago I think this is an issue you will have to file with Gradle or maybe kapt. Dagger just registers its processor and relies on Gradle to run it whenever a source needs to be reprocessed. In this case, it seems like Gradle/kapt isn't doing that properly, and unfortunately I don't think there's anything we can do on our side to fix that.
danysantiago
commented
2 years ago You can try investigating if KAPT is reporting the source changes and running the processors by adding a few debug options to the build scripts:
// in gradle.properties
kapt.verbose=true
// in build.gradle were kapt plugin is applied
kapt {
javacOptions {
option("-XprintProcessorInfo")
option("-XprintRounds")
}
}
freszu
commented
2 years ago I did run the sample with these flags, but i am not sure i can make proper conclusions out of it
StringConsumer was marked as changed but i can't point the reason for which SomeActivity_MembersInjector was removed (after all it shouldn't change so that would be the expected behavior for me) or not ended up being regenerated
danysantiago
commented
2 years ago Thanks, I still believe this is an issue with KAPT and I suggest you report it to https://youtrack.jetbrains.com/
If you use no build cache things work fine: ./gradlew compileKotlin --no-build-cache which is a big indicator there is something going on with incremental compilations, something Dagger has no real control off.
Moreover, if you downgrade Kotlin to 1.5.32, the issue is not reproducible, which is a clear indicator of some type of regression with KAPT.
From Dagger's perspective, what happening is that Dagger checks if the generated members injector, SomeActivity_MembersInjector is in the classpath (meaning it was already generated) and then it skips generating it even though SomeActivity is indeed being reprocessed. This is a common scenario that happens if you run Dagger in a library module with @Inject, Dagger will generated member injectors and factories early so those don't have to be generated when processing the @Component in a module that consumed the library.
When you make a change in a source, Gradle + KAPT will delete the generated sources relevant to that class, because they are invalid, but is seems that even though the generated sources are deleted, the classes are still in the classpath, which makes Dagger believe they are already generated, but in the end they are not part of the compilation. The location from which SomeActivity_MembersInjector is coming from is interesting, when attaching a debugger it points to build/classes/java/main/SomeActivity_MembersInjector.class even though as part of the incremental compilation, the previous sources in build/generated/source/kapt were all deleted, so I think the issue relies in the cache or incremental data not being correct.
PavelKapustsin
commented
2 years ago Just a simple note here, that's the problem isn't new for the KAPT and there are already a few tickets created. https://youtrack.jetbrains.com/issue/KT-21735 https://youtrack.jetbrains.com/issue/KT-38557 https://youtrack.jetbrains.com/issue/KT-40750 etc
Though, not a one has been actually fixed so far.
When changing visibility of injected element dagger compilation crashes with
this can be resolved by cleaning the build cache after which compilation goes just fine.
I can reproduce the issue with my sample in dagger 2.41, 2.40 didn't check further but i think we faced this issue for some time in our Android App as well.
The minimal reproduction showing this issue with change visibility comment:
The full ready to run project can be found here: https://github.com/freszu/DaggerVisibilityChangeBug