I want to process all functions returning a `kotl...

# ksp

[Paul Woitaschek]

I want to process all functions returning a kotlinx.coroutines.flow.Flow. When entering visitFunctionDeclaration is there any way to get the complete return type? (not only "Flow")?
The only solution I have found so far is to call:
function.returnType?.resolve()?.declaration?.qualifiedName?.asString() but that would force me to resolve just all functions which is documented as "expensive". Is there a way to do it without resolving all functions?

[efemoney]

Use name == “Flow” as condition to gate the resolution

[Paul Woitaschek]

Does that handle typealiases?

[Paul Woitaschek]

or will that if I write typealias Wolf<T> = Flow<T> lead to Wolf?

[efemoney]

I’d need to confirm but there should be special consideration for type aliases

side note: Just noticing wolf is flow in reverse lol 😄

[Paul Woitaschek]

Yeah me too 😛

[efemoney]

Just took a look at the API and type aliases make it tricky but you can still be clever and avoid unnecessary resolution.

For instance you could visit type aliases to mark “interesting” ones (typealiases of Flow or typealiases of the aforementioned typealiases) that in a subsequent round of processing you can then search for in function return types

[Grégory Lureau]

What if there is another class named Flow in another part of the project? You can't visit built dependencies, so you're forced to resolve the type no?

[Paul Woitaschek]

Yes but efemoneys suggestion is good. At least it does not result into resolving everything

[Grégory Lureau]

I had to make a patch to write the original file and check import myself to get the package name. Pretty sure it's not the best approach but could it be less costly that resolution?
Maybe also visiting imports/files and mark them could be an option.
A bit weird to me to have simple name instead of full name as the default value when it's likely to be determined from the file itself.

[evant]

been wondering about requesting something like this myself. I could see at being a performance win when checking a lot of types. It would also allow you to continue even if the type isn't resolved. (Would fixe cases like https://github.com/evant/kotlin-inject/issues/155). One big issue with it is wildcard imports though. As soon as a file has one you don't know where it came from.

[Grégory Lureau]

Here's my current (shitty) patch if it can give some ideas (I wrote it when I was facing an issue when resolving classes in jsMain of a KMP project from another module). We use ktlint on the project and avoid wildcard imports but you're right it's not safe to use that approach with wildcards. Also we could check if the import is found in the file, and if not found call resolve() as a last resort, but I'm not sure if it's less or more costly than the resolve eventually.

[Jiaxiang]

gating resolution based on name is a good optimization, however it does not handle type alias well. Actually in KSP development we had similar challenge when implementing getSymbolsWithAnnotation , effort to optimize with typealias in mind is non-trivial. I would suggest use annotation to mark the symbols you want to process.