I think I’ve noticed a bug with deferred symbols. ...

# ksp

[elihart]

I think I’ve noticed a bug with deferred symbols. If I defer a property symbol (KSPropertySetterDescriptorImpl) it does not show up again in the next round when using getSymbolsWithAnnotation.

[elihart]

Deferring like this works fine for classes, but not for my annotated properties within the class

[Jiaxiang]

Descriptor based KS symbols are not meant to be deferred

[elihart]

ah

[elihart]

could you update the docs? https://github.com/google/ksp/blob/main/docs/multi-round.md

I don’t think that is in there

[Jiaxiang]

deferred is meant for invalid symbols, so we actually discard descriptor based symbols since it is not supposed to have invalid symbols from class path

[Jiaxiang]

the behavior was added after the document was created. Let me add it to multiple round doc..

[Jiaxiang]

thanks for catching this!

[elihart]

thanks for explaining.

My use case is that historically (with kapt) my processor looks up annotations both on the class and on properties within the class with getSymbolsWithAnnotation .

The class has some error types elsewhere, so I defer it, but then in the next round I can no longer look up the properties.

The workaround I believe is to not use getSymbolsWithAnnotation to get annotated symbols within an annotated class, but instead iterate through it with a visitor or other pattern. That should be fine, but many javac processors don’t do this so a direct port may not work (if they have to defer)

[Jiaxiang]

so the behavior of not deferring symbols only applies for symbols from class path, did you mean that you are having symbols from class path that contains some error types?

[Jiaxiang]

when we made the change to discard descriptor based deferred symbols, we made an assumption that symbols from libraries should always be valid, I can think of invalid symbols with custom compiler but that looks too hack use case to me.

[elihart]

I think that decision makes sense, let my try to rephrase my problem.

For an aggregating processor I need information about all symbols to be available before I can generate my file.

If there is a mix of invalid and valid symbols the invalid symbols must be deferred. In this case it is simpler to defer ALL symbols, even the valid ones, so I can process them all at the same time. Otherwise I need to process them in batches and hold onto that information across rounds which can be difficult because Symbols cannot be used across rounds (https://kotlinlang.slack.com/archives/C013BA8EQSE/p1635301609028500)

But that design decision makes it so I can’t defer the valid symbols, and am forced to process them in a different round then the invalid ones

[elihart]

Generally I think this behavior is fine, its just a little hard to understand and error prone / confusing if you don’t adhere to KSP rules exactly. Also it is quite different from Javac so porting large legacy processors (as I’m doing now 😛 ) is giving me a lot of headaches and I’ll have to rework the approach to match what KSP expects.

[Jiaxiang]

Got it. So yes you are right about symbols can’t be reused cross rounds, therefore KSP did some additional efforts to re-construct deferred symbols before the start of next round, which might be giving a sense that you can use deferred symbols to pass symbols across rounds.. I guess I need to rephrase document in a better way to clear up such confusion.

[elihart]

thanks, that would be helpful.

I did see this

To avoid unnecessary reprocessing of symbols, getSymbolsAnnotatedWith returns only those symbols found in newly generated files.

which seemed like a mistake since I realized deferred symbols do get returned again by getSymbolsAnnotatedWith in some cases

[Jiaxiang]

🤦 yet another document error to be fixed, thanks for catching

[elihart]

sure, I know it’s very hard to keep that up to date 😅

In a similar vein, it would probably be helpful to update the kdoc of getSymbolsWithAnnotation in the source itself with these details