set the channel description: working group channel for AndroidX's KSP KAPT abstraction.

set the channel description: working group channel for AndroidX's KSP KAPT abstraction. https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:room/room-compiler-processing/

set the channel topic: KAPT -> KSP

For Showkase we generate kotlin code that can call Composable functions. With XProcessing though afaict there isn’t a way to tell whether a function is top level or not. The

XMemberContainer

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 caes

Hi, We are looking into optimizing parts of XProcessing (focus so far was always consistency). One of these is the

getAllMethods

function in

XTypeElement

which requires resolving overrides ( = expensive). Right now, we group methods with their

jvmName

to reduce the # of calls to

overrides

checks, but resolving

jvmName

requires resolving parameter types (in case they are value classes). In practice though, @JvmName annotation is not allowed for overriding methods or open methods, such that we could technically group methods by their visible name (but still use jvmName if we ever need to do an override check). e.g. you cannot do these:

@JvmName("foo")
open fun x2() {
}

@JvmName("notf1")
override fun f1() {
}

Now, developers can suppress that error (🤦 ) but we are thinking of either just not supporting it (as in, we would ignore the JvmName for those methods for overrides checks) or maybe add a new config to take that into account (might be a weird option to have). Wanted to share here if anyone has some comments. FYI we are looking at a 15-20x speed improvement for our sample case if we can do this change (which should be be fairly common as most processed methods are not overrides)

here is a prototype: https://android-review.googlesource.com/c/platform/frameworks/support/+/1949590

Hi, I'm working on moving the

enclosingElement

field up to

XElement

(https://android-review.googlesource.com/c/platform/frameworks/support/+/1948583). This means that now every element can use this field to access its parent. The field is nullable and will be null for file member containers in Kotlin and top-level class elements in Java (we don't support package or module elements for now). This brings some breaking changes as we unified the naming for some subtypes. For example, fields like

JavacEnumEntry.enumTypeElement

,

JavacMethodParameter.enclosingMethodElement

, and

KspExecutableParameterElement.enclosingMethodElement

are replaced with this

enclosingElement

. We also added a

XElement.closestMemberContainer

with this change to get the closest containing member container. This field is non-nullable and could return itself if

this

is already a member container. Please let me know if you have any concerns.

Is there any ETA for when a new room-compiler-processing alpha will be published? I can use a snapshot internally, but since we have several open source processor libraries it’s less feasible to get them on the same snapshot. the xprocessing API changes make it important to coordinate the update across all processors at the same time I think

I’m seeing this crash in the last 2.5.0-alpha02

java.util.NoSuchElementException: List is empty. |  
-- | --
  | at kotlin.collections.CollectionsKt___CollectionsKt.last(_Collections.kt:416) |  
  | at androidx.room.compiler.processing.javac.ElementExtKt.suspendOverrides(ElementExt.kt:114) |  
  | at androidx.room.compiler.processing.javac.JavacMethodElement.overrides(JavacMethodElement.kt:131) |  
  | at androidx.room.compiler.processing.DeclarationCollectorKt$collectAllMethods$1.invokeSuspend(DeclarationCollector.kt:103) |

I spent some time debugging the kapt process to better figure out what is going on. it’s very strange, we have this property in a kotlin class

open val argumentsKey: String = "airbnb:args"

that is overridden in the module being compiled

override val argumentsKey: String = Mavericks.KEY_ARG

For some reason the kotlin metadata (and therefor xprocessing) think it is a suspend function. This is using kotlinx-metadata 0.4.2, but I also tried the newer 0.5.0 and it has the same problem.

If I change the overridden property to use

get() =

then it is no longer interpreted as a suspend function and the module compiles correctly

it seems like a bug in kotlinx-metadata, but i suppose it could also be related to how xprocessing parses the metadata? i don’t know where something like this should be filed and I don’t have a simple repro project to share

FYI, aosp/2155639 fixed some inconsistencies between Javac's concept of

ExecutableElement

and XProcessing's

XExecutableElement

which may cause some subtle breaking changes when you upgrade. The context of why we wanted to make that change is explained in the description of that CL, but the tl;dr is that the parameter and return types of

XExecutableElement

will no longer automatically be resolved "asMemberOf" whichever enclosing type element was used to get the method. As an example of a fix we had to make in Room due to this change see https://android-review.googlesource.com/c/platform/frameworks/support/+/2155639/14/room/room[…]c/main/kotlin/androidx/room/processor/DaoProcessor.kt. In general the fix will be to manually call

XExecutableElement#asMemberOf(XType)

when you need the resolved types. If you have any other questions about the change feel free to ask. Thanks!

Hey, just curious when the next version of xprocessing might be published. In particular I think we’re blocked by the kotlinx metadata issue that was mentioned in this dagger issue https://github.com/google/dagger/issues/3701#issuecomment-1380724453 Dany said he was fixing it in xprocessing, but afaik a version hasn’t been published since then. (Yes, we can publish our own version off the snapshot, but it is harder to do that across all of the open source processors we have)

I'm not sure if it is included or not but i think we have a release scheduled for March 22nd