found a bug and filed on dagger, but I think this may actually/also be a KSP bug <https://github.com...

# ksp

[Zac Sweers]

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

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

[Ting-Yuan Huang]

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

[Zac Sweers]

I’d actually ignore the KMP bits entirely, this happens with any typealias

[Zac Sweers]

I linked a repro in my original issue https://github.com/google/ksp/issues/1676

[Ting-Yuan Huang]

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.

[Zac Sweers]

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?

[Ting-Yuan Huang]

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.

[Zac Sweers]

hmm not seeing this to be the case https://github.com/google/ksp/issues/1676#issuecomment-2232410795

[Ting-Yuan Huang]

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)