-
Notifications
You must be signed in to change notification settings - Fork 2k
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
[KSP] Dagger-KSP does not see typealiased dagger annotations #4356
Comments
I've searched the KSP issue tracker and found a previous issue that, amusingly, I filed months ago and forgot about google/ksp#1676. I'm going to consolidate this over to that. My solution in that issue is similar to the first alternative I listed above |
Reopening as, according to the KSP folks, this is actually the responsibility of the symbol processor to resolve the underlying aliased type. |
After some discussion [here](google/dagger#4356) I learned we should be handling this ourselves
I filled https://issuetracker.google.com/355006385 in XProcessing which is where most type aliases are resolved for Dagger. We already resolve type alias in various places but looks like we never needed to for annotations, so this seems something that just might be fixed with changes in XProcessing. |
Edit When I originally wrote this, I thought it was related to the use of expect/actual in multiplatform. Upon further testing, it appears to be just related to the use of a typealiased annotation in any context
I have a multiplatform project where I use Dagger in jvm/android. To accomplish this in a way that still allows for use of standard injection annotations in common sources, I use expect/actual + typealiases to actualize them in jvm/android compilations to the real dagger annotations.
However, it appears that dagger-ksp then misses these types because it doesn't resolve the aliased type of the annotations. I'm not sure if this is a dagger issue or a KSP issue (i.e. is KSP not correctly resolving that the annotated symbol is actually an alias to the intended type).
Two alternative solutions:
my.custom.AssistedFactory
should also be treated as@AssistedFactory
".The text was updated successfully, but these errors were encountered: