Implement KSP support for ContributesMultibinding #740
Conversation
ZacSweers
force-pushed
the
z/ksp/contributesMultibinding
branch
from
2e21ec6
to
ed5286c
Compare
| } | ||
| is AnvilCompilationMode.Ksp -> { | ||
| val processor = simpleSymbolProcessor { resolver -> | ||
| resolver.getSymbolsWithAnnotation(MergeComponent::class.qualifiedName!!) |
There was a problem hiding this comment.
Is there any reason to use qualifiedName over canonicalName or vice versa? Just asking since I noticed you used getSymbolsWithAnnotation(ContributesMultibinding::class.java.canonicalName) in the code gen
There was a problem hiding this comment.
No functional difference, one is just java reflection and the other is kotlin reflection. Thinking we could maybe standardize toward the latter to make it more KMP-friendly in the future?
|
|
||
| val dependencies = Dependencies(aggregating = false, sources = emptyArray()) | ||
| val file = env.codeGenerator.createNewFile(dependencies, packageName, "$fileName.kt") | ||
| // Don't use writeTo(file) because that tries to handle directories under the hood |
There was a problem hiding this comment.
What ends up happening if writeTo was used here? Would it result in an obvious failure or something more cryptic/delayed? Thinking about if this is a footgun that could bite us elsewhere in the future
There was a problem hiding this comment.
Under the hood Kotlinpoet tries to make directories for package segments, but KSP does that for us already so we don't want to double-nest. It wouldn't obviously fail, it would just create a duplicate bested package structure. I don't think it's something we need to really guard against as this is the only place we do this custom.
|
idk what to do about that windows job |
JoelWilcox
force-pushed
the
z/ksp/contributesMultibinding
branch
from
3052d00
to
e215900
Compare
Fairly straightforward, but added support for a
SimpleSymbolProcessorfor use in tests.