elihart
10/28/2021, 8:36 PMList<out T>
it should be covariant, and javac processors view it that way, but KSP reports the argument as invariant. I have a repro using xprocessing. I don’t think it is a problem within xProcessing because the debugger shows the originating KSTypeImpl
to have an invariant argument
@Test
fun testListVariance() {
val libSource = Source.kotlin(
"lib.kt",
"""
class KotlinClass {
fun foo(list: List<CharSequence>) {}
}
""".trimIndent()
)
runProcessorTest(listOf(libSource)) { invocation ->
val clazz = invocation.processingEnv.requireTypeElement("KotlinClass")
val param = clazz.getDeclaredMethods().single().parameters.single()
if (invocation.isKsp) {
expectThat(param.type.typeName.toString())
.isEqualTo("java.util.List<java.lang.CharSequence>")
} else {
expectThat(param.type.typeName.toString())
.isEqualTo("java.util.List<? extends java.lang.CharSequence>")
}
}
}
Jiaxiang
10/28/2021, 8:50 PMTing-Yuan Huang
10/28/2021, 9:45 PMjava.util.List
, instead of kotlin.collections.List
?param.type.typeName.toString()
prints use-site variance instead of declaration-site variance?Jiaxiang
10/28/2021, 9:59 PMTing-Yuan Huang
10/28/2021, 10:00 PMJiaxiang
10/28/2021, 10:00 PMelihart
10/28/2021, 10:03 PMwhy it isThat’s the JavaPoet TypeName representation that xprocessing exposes. Since it is for java codegen it converts kotlin instrinsics to the java equivalent writing, instead ofjava.util.List
kotlin.collections.List
List<out CharSequence>
gives a warning because List
already marks its type as out
. so the type should always be covariant - it is inheritedTing-Yuan Huang
10/29/2021, 3:20 AMelihart
10/29/2021, 4:43 AME
as covariant.
It seems like a bug with XProcessing then, so I’ll file thereTing-Yuan Huang
10/29/2021, 4:58 AM