You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With Dagger’s upcoming support for KSP, we should make Anvil work with this new pattern
It’s a bit tricky, as it has always worked up to this point by running a special IR plugin during kapt stub generation to modify/add annotations to certain classes for Dagger’s use in kapt. Obviously that won’t work in a KSP world since it’s all one task.
What I’m thinking currently is something clever like this:
Anvil exposes its own delegating SymbolProcessor that handles running Dagger’s.
It would then decorate KSP’s Resolver APIs to intercept them and add this metadata (annotations, etc) to the KSP types on their way through.
So for example, this type
@MergeComponent(...)
interfaceAppComponent
This processor would then intercept that and construct a new KSClassDeclaration that almost entirely mirrors the previous except that it adds the merged @Component annotation that anvil synthesizes instead.
Lastly, when resolving annotated elements, it would intercept searches for Component types and forward the request as a @MergeComponent request instead.
Same patterns would be used for merged modules.
While weird and obviously not something KSP could officially support, I do think this could work more or less entirely within the bounds of KSP’s public API.
The text was updated successfully, but these errors were encountered:
ZacSweers
changed the title
Support Dagger KSP
Support Dagger KSP in Anvil
Apr 27, 2023
I think an initial start to this may require limiting Anvil to only running in a separate compilation. Anvil supports generating more sources and incurring subsequent rounds, but it's not totally clear if that will be possible while running under KSP, because this information would need to be conveyed to KSP and delay the component processing to a later round.
Filing an issue for posterity/tracking. I'm planning to take a stab at this.
Pasting what I wrote in kotlin-lang here: https://kotlinlang.slack.com/archives/C013BA8EQSE/p1669155272374909
With Dagger’s upcoming support for KSP, we should make Anvil work with this new pattern
It’s a bit tricky, as it has always worked up to this point by running a special IR plugin during kapt stub generation to modify/add annotations to certain classes for Dagger’s use in kapt. Obviously that won’t work in a KSP world since it’s all one task.
What I’m thinking currently is something clever like this:
Anvil exposes its own delegating
SymbolProcessor
that handles running Dagger’s.It would then decorate KSP’s
Resolver
APIs to intercept them and add this metadata (annotations, etc) to the KSP types on their way through.So for example, this type
This processor would then intercept that and construct a new
KSClassDeclaration
that almost entirely mirrors the previous except that it adds the merged@Component
annotation that anvil synthesizes instead.Lastly, when resolving annotated elements, it would intercept searches for
Component
types and forward the request as a@MergeComponent
request instead.Same patterns would be used for merged modules.
While weird and obviously not something KSP could officially support, I do think this could work more or less entirely within the bounds of KSP’s public API.
The text was updated successfully, but these errors were encountered: