ksp: more accurately represent function types #1742
Conversation
When converting a KSTypeReference, represent a function type with LambdaTypeName. The better matches the source code and allows for receiver types (ex: String.() -> Unit) to be represented correctly.
evant
force-pushed
the
ksp-function-types
branch
from
66a3ea2
to
09fd8ff
Compare
There was a problem hiding this comment.
Nice improvement 👍
One open question (that may be annoying to test) – do you know what happens when you have a function with more than 22 parameters? See https://github.com/Kotlin/KEEP/blob/master/proposals/functional-types-with-big-arity-on-jvm.md
There was a problem hiding this comment.
I don't know anything about KSP but the test improvement seems very nice. Should we add a test for direct usage of Function interfaces to ensure they work? Or are we just going to safely assume that since they're otherwise plain 'ol types.
@ZacSweers can have the final say with regard to the validation thing (which I have no idea wtf that is)
...p/test-processor/src/main/kotlin/com/squareup/kotlinpoet/ksp/test/processor/TestProcessor.kt
Outdated
Show resolved
Hide resolved
Yep they are treated just like any other type (just verified locally). No strong opinions here so I wouldn't mind adding to the test if we feel it's useful. |
Seems to generate fine if that's what you are asking, I could add something to the test if you want? |
…poet/ksp/test/processor/TestProcessor.kt Co-authored-by: Jake Wharton <github@jakewharton.com>
|
Yeah let's add a test just for coverage if you don't mind, otherwise lgtm 👍 |
|
Sorry I wasn't specific – let's cover both direction |
|
Sorry, I'm a bit confused on what we'd actually be testing with that. From a codegen perspective nothing changes at 23+ params. According to the proposal you linked the generated bytecode is different but I don't think that smoke test is testing that anyway? |
|
I updated it with what I meant. You're right, I just wanted to be sure :). I was curious if KSP would render that as a KSCallableReference still or if it would represent it as a |
|
heh ok |
|
Thanks! |
When converting a KSTypeReference, represent a function type with LambdaTypeName. The better matches the source code and allows for receiver types (ex: String.() -> Unit) to be represented correctly.