Implement basic KSP interop #1146
Conversation
| get() = emptyMap() | ||
|
|
||
| override fun get(index: String): TypeVariableName { | ||
| error("No TypeParameter found for index $index") |
There was a problem hiding this comment.
nit: should it throw something like UnsupportedOperationException?
There was a problem hiding this comment.
Not in this case I think, this is an unexpected condition rather than something unsupported or unimplemented
There was a problem hiding this comment.
Called out as based on the message it may seem that this API will return something for a different index, when in fact it will always throw.
There was a problem hiding this comment.
ahhh I didn't realize where you were commenting (was looking on mobile). Good point
There was a problem hiding this comment.
Went with NSEE to match what we do in metadata for this 74e323a
| * | ||
| * @see FileSpec.originatingKSFiles | ||
| * @param codeGenerator the [CodeGenerator] to write to | ||
| * @param aggregating flag indicating if this is an aggregating |
There was a problem hiding this comment.
nit: "aggregating annotation processor"?
There was a problem hiding this comment.
Good catch, though I think we want to say "symbol processor"
| * | ||
| * @see FileSpec.originatingKSFiles | ||
| * @see FileSpec.writeTo | ||
| * @param aggregating flag indicating if this is an aggregating |
| } else { | ||
| "Function$count" | ||
| } | ||
| ClassName("kotlin.jvm.functions", functionSimpleName) |
There was a problem hiding this comment.
Is there a multiplatform-friendly alternative?
There was a problem hiding this comment.
I'm not sure to be honest. The spec focuses mostly on JVM and agnostic impls, but doesn't explicitly call out how it works on other platforms. Seeing as we do this here and in metadata, mind if we save this for a later day?
There was a problem hiding this comment.
For sure, especially since I believe KSP only targets JVM with 1.0? Or it will support MPP?
There was a problem hiding this comment.
KSP will support MPP yeah (insofar as it will be able to run code gen for MPP projects)
Co-authored-by: Egor Andreevich <egor@squareup.com>
Co-authored-by: Egor Andreevich <egor@squareup.com>
|
Talked offline, will work at some basic test infra for this in a followup PR. Will likely entail writing a sample processor that parses a class and then generates code that shows it read it correctly. |
This starts a basic KSP interop project, with extensions covering common use cases like...
TypeNametype conversionFileSpectoCodeGenerators@KotlinPoetKspPreviewannotation while we fine-tune the API.This is largely upstreamed and cleaned up from the Moshi KSP implementation currently being upstreamed over here.
What this does not attempt to do: the full "give me a class and I'll give you a TypeSpec of the API" like kotlinx-metadata interop does. I'm open to considering it if we think it's worthwhile, but unlike with metadata we don't need to run everything from a class's
@Metadataannotation for this to work, so I'm currently erring on the side of keeping the interop lightweight. There could be a good use-case for some existing helpers likeoverriding,AnnotationSpec.get(),ParameterSpec.get(), etc, but we can see if the community asks for that later.TODO: