So I'm trying to handle multiple rounds and having...

# ksp

[evant]

So I'm trying to handle multiple rounds and having trouble figuring out how to have the best user experience. Is there some way to distinguish between a type will be available in a later round and one that will never be? I've run into cases where ksp will always fail to resolve the type (trying to reference a generated class for view binding is a good example). And having it just skip and never generate anything isn't great.

[Zac Sweers]

I think the way that regular apt handles this is an API for checking if the current round is the final round. Maybe KSP should have a similar API?

[evant]

Hm, https://kotlinlang.org/docs/ksp-multi-round.html claims that

If unprocessed deferred symbols still exist when the termination condition is met, KSP logs an error message for each processor with unprocessed deferred symbols.

But I haven't seen anything logged.

[Zac Sweers]

ah gotcha

[yigit]

We had similar issues recently that Dany worked on. I think this is the related cl: https://cs.android.com/androidx/platform/frameworks/support/+/ab457c75d88a35c96eda872b302ced2717c9416c

[evant]

Room will reject elements with missing types up to the last round, where it will try to continue processing as much as possible and generate code along with reporting errors including those os missing types.

That's the behavior I'm looking for, will take a look

[evant]

Also big 👍 in the work in room. Just switched to androidx.room.room-compiler-processing-testing because of https://github.com/tschuchortdev/kotlin-compile-testing/issues/72

[Jiaxiang]

You should see the unresolvable deferred symbols in a KSP warning level log. Were you not able to see any information from log while having the error types returned in the process() function?

[evant]

ooh I think I know what's happening. Looks like getSymbolsWithAnnotation will skip already processed files even if they are returned from process() . I guess you need to hold on to unprocessed files to re-process them? Seems like something could be streamlined here api-wise

[evant]

ok this is what I came up with https://github.com/evant/kotlin-inject/blob/b9a7703ed9fa7562a2f9b873f6268213c29a00[…]c/main/kotlin/me/tatarka/inject/compiler/ksp/InjectProcessor.kt does this make sense?

[Jiaxiang]

Looks good to me, the key here is

--- return emptyList()
+++ return differed

processors have the obligation to return any invalid symbols if they are still interested in that. I will add it to document to clear up any confusion.

[evant]

so the part that caught me up wasn't that you needed to return them, but that you need keep track of them yourself for reprocessing. I erroneously thought they'd be given back as new on the next round.