Hi! Is it intentional that `resolver.getSymbolsWit...
# ksp
d
Hi! Is it intentional that
resolver.getSymbolsWithAnnotation
returns deferred symbols from previous rounds from all symbol processors, not only the current one? This line of code:
Copy code
deferredSymbols.values.flatten().mapNotNull { it.restore() }.toSet()
in ResolverAAImpl.
deferredSymbols
is a map with symbol processor as a key. But
values.flatten
combines all deferred symbols from all processors. Isn’t it unfortunate that processors are not isolated in this sense, and if one processor relies on some deferring logic of its own, another one can spoil it?
h
But how else do you want to support processing generated symbols from another processor?
1
d
Oh, you caught me there! Of course, you’re right. I was doing some complicated logic with deferring and missed the simplest basic scenario 🙂 Will have to do some filtering of the previously deferred symbols
But wait a second, maybe that’s not so obvious… The scenario you’re talking about is perfectly handled by the fact that newly generated files from all processors are visible to all processors. But I’m talking about deferred symbols.
getSymbolsWithAnnotations
returns the sum of newly generated and deferred symbols. There is no doubt that all newly generated symbols have to visible to all processors. But it’s not clear why deferred symbols have to follow the same logic. If I, as a processor author, decide that the declaration is ready and I have already handled it and I defer some other declarations but not this one, I don’t expect it to be returned to me again, in the next round. But it will be returned, if another processor decides it cannot handle it just now, and defers it. So, effectively, in order to avoid processing something twice, I will always have to check that symbols returned to me are really either new or have been deferred by my processor. And that check is exactly what the map from processor to deferred symbols already contains by being a map. Or am I missing something?