found a bug and filed on dagger, but I think this ...
# ksp
z
found a bug and filed on dagger, but I think this may actually/also be a KSP bug https://github.com/google/dagger/issues/4356. In short - if you have
Copy code
typealias CommonAnnotation = RealAnnotation
and then someone calls
getSymbolsAnnotatedWith("com.example.RealAnnotation")
, KSP does not return any symbols annotated with
CommonAnnotation
even though it is an alias (or in the case of the bug linked above - actualized) to
RealAnnotation
t
May I know in which Gradle task / compilation target it failed? I.e., is the target source that contains
actual
present in the failing ksp task? I feel that this is MPP specific, because for non-MPP cases, we have some tests covering this: https://github.com/google/ksp/blob/main/test-utils/testData/api/getSymbolsFromAnnotation.kt
z
I’d actually ignore the KMP bits entirely, this happens with any typealias
I linked a repro in my original issue https://github.com/google/ksp/issues/1676
t
Thanks. I added a comment in the bug. If I understand the issue correctly, type aliases need to be resolved to the underlying types explicitly in order to do the FQN comparison in the linked test case. This is a trade-off between the convenience and expressiveness. Processors should be able to get the desired behavior by expanding type aliases.
z
I see. Just to clarify, are you saying in your comment that KSP does return those symbols, it’s just on the processor to check if their annotations later resolve to the target annotation?
t
Yes, KSP returns whatever annotations found on a
KSAnnotated
. It just doesn't expand them. If
Resolve.getSymbolsWithAnnotation
doesn't work for you, you'll have to expand both the querying annotation and annotations on
KSAnnotated
before fqn comparison.
👍 1
z
t
You're right. The current KSP model requires processors to call
findActuals
on the
KSClassDeclaration
you saw. Unfortunately
findActuals
hasn't been properly implemented in KSP2. I'll address this in 1.0.25 (1.0.24 will likely be a hotfix)
🎉 1