New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Dagger KSP in Anvil #704
Labels
enhancement
New feature or request
Comments
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: