elihart
12/03/2021, 7:29 PMXMemberContainer
lets top level functions be represented and access the JVM name, which is fine for Java codegen, but it would be nice to have a direct way to tell this info for kotlin codegen.
Right now I’m using reflection to get the kotlin metadata in the kapt case, and using the assumption that the XMemberContainer
is not an XTypeElement in the KSP caesyigit
12/03/2021, 7:32 PMelihart
12/03/2021, 7:53 PMThe [XType] for the container if this is an [XTypeElement]
, but according to the enclosingElement
kdoc the member container is an XTypeElement in certain cases.
Is the type null even in those cases?@Test
fun isTopLevelFunction() {
val libSource = Source.kotlin(
"lib.kt",
"""
@com.airbnb.android.showkase.processor.models.MyAnnotation
fun foo() {}
class Bar {
fun enclosedFoo() {}
}
""".trimIndent()
)
runProcessorTest(listOf(libSource)) { invocation ->
val barClass = invocation.processingEnv.requireTypeElement("Bar")
expectThat(barClass.getDeclaredMethods()
.single())
.get { enclosingElement.type }
.isNotNull()
expectThat(invocation.roundEnv.getElementsAnnotatedWith(MyAnnotation::class))
.single()
.isA<XMethodElement>()
// This fails
.get { enclosingElement.type }
.isNull()
}
}
danysantiago
12/03/2021, 9:17 PMXMemberContainer.type
is not a good check due to the KAPT / KSP inconsistency. For KAPT there is always a container and type
will not be null. And in KSP only if the top-level function is in source, it won’t have a type
but if its from compiled code it will.XMemberContainer
is which is explained here https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:room/roo[…]droidx/room/compiler/processing/XExecutableElement.kt;l=28-35elihart
12/03/2021, 11:24 PM