Does a processor applied to a given module have visibility on elements that are invisible to the sou...

# ksp

[Forrest Pangborn]

Does a processor applied to a given module have visibility on elements that are invisible to the source for that module if those annotated elements exist within a dependency?

What I'm looking to accomplish is to support generation of some classes internal to some collection of child modules, but then provide a simple way for resolving the generated classes in a consumer module. The mechanism for this would probably be by generating a map where keys are an interface the generated classes implement, where the keys are internal to the same places the generated classes (and thus only used in the modules where internal visibility applies), but I'm looking to have one central registry if possible, as that could itself also be generated.

So:
• Module A depends on Module B.
• Module B contains some elements annotated with @XYZ .
When a processor resolving elements annotated with @XYZ is applied to Module A, will the resulting processor execution resolve those elements from Module B that have been annotated with @XYZ?

[Jiaxiang]

you won’t be able to retrieve these annotated symbols in module B with KSP’s getSymbolsWithAnnotation API, if you can find a way to get these symbols somehow, then you can still process them, but I won’t be optimistic on this.

[Forrest Pangborn]

you won’t be able to retrieve these annotated symbols in module B with KSP’s getSymbolsWithAnnotation API

just to clarify: this is because the sequence of elements from the resolver wouldn't include them?

thanks so very much for the ridiculously quick reply btw 🙂

[Jiaxiang]

yes, the resolver will only look up in source code files in the compile module for annotated symbols. Theoretically you can get the symbols from dependencies with fully qualified name to process but I assume that is not practical for real use.

[Forrest Pangborn]

so the limiting factor here for me isn't the visibility, but rather just the module boundaries

[Forrest Pangborn]

ah, just found this in here (that you appeared to have worked on, thank you!). https://github.com/google/ksp/issues/372

i think i may be able to use getDeclarationsFromPackage to accomplish what i'm aiming for.

[Jiaxiang]

that API is still not a general purpose API, if that works it will be great 🙂

[Forrest Pangborn]

well - happy to give it a go! if it doesn't work, i'll just find another way to the end result 🙂

[Grégory Lureau]

I have done a trick where I used a file annotation (, or an annotation on a typealias) that have a KClass<*> parameter. It offers the possibility to reference classes from outside the compilation module, and get the KSClassDeclaration of those classes. I'm not sure, but maybe it can help you?

[Forrest Pangborn]

good to know that's another option!

it looks like in your example, the use of your KustomExportGenerics annotation is in the module where the processor is applied, right? so to conform it to my described scenario above:
• @file:KustomExportGenerics is used in Module A, referencing classes from Module B.
• Processor is applied to Module A but can resolve KSClassDeclaration instances for the classes in Module B that are referenced in the KustomExportGenerics

[Grégory Lureau]

Yes, that's it.

[Forrest Pangborn]

great 🙂 will make a note of this approach and see if it helps me