[KSP] Component processing is not deferred if there are unresolved symbols in the current round

[jonamireh]

It seems like when using Dagger KSP, component processing is still run even though the current round is missing symbols

More concretely, we have a KSP code generator that creates an interface and then we reference that generated interface as a supertype of an @Component interface. Dagger appears to run its component processing, despite not being able resolve that generated interface, and creates the ComponentImpl class anyway, which finally causes javac to fail, because Dagger never implemented the methods defined by that generated interface

//Generated by custom KSP generator
interface SomeActivityInjector {
  fun inject(activity: SomeActivity)
}

@Component
interface SomeComponent : SomeActivityInjector

// Generated by Dagger
private static final class SomeComponentImpl implements SomeComponent {
  // no `inject` method; javac can't compile this
}

Unclear but it might be relevant that KspBasicAnnotationProcessor does not defer rounds: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:room/room-compiler-processing/src/main/java/androidx/room/compiler/processing/ksp/KspBasicAnnotationProcessor.kt;l=65-70?q=KspBasicAnnotationProcessor

[jonamireh]

I created a quick project to show a simple repro: https://github.com/jonamireh/dagger-ksp-component-bug

[danysantiago]

Thanks for the repro project, really helpful. Doing a quick analysis, I think you are essentially seeing a variation of google/ksp#1443, where Dagger in KSP has a hard time validating to-be-generated super types / super interfaces. I don't have a solution yet, but I'll try to figure something out soon.

[jonamireh]

Thanks @danysantiago ! I went ahead & grabbed a new copy of xprocessing from the AndroidX CI & then recompiled Dagger from source with said JAR to see if that fixed our issue – it did 🎉

So whenever Dagger pulls in the new xprocessing JAR & releases, we should be good to go