yigit
12/01/2021, 12:46 AMyigit
12/01/2021, 12:49 AMyigit
12/01/2021, 12:49 AMelihart
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
01/13/2022, 5:58 PMgetAllMethods
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)yigit
01/14/2022, 1:44 AMKen
02/03/2022, 7:09 PMenclosingElement
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.elihart
04/27/2022, 7:48 PMelihart
07/15/2022, 1:18 AMjava.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) |
elihart
07/20/2022, 7:31 PMopen 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.elihart
07/20/2022, 7:32 PMget() =
then it is no longer interpreted as a suspend function and the module compiles correctlyelihart
07/20/2022, 7:33 PMBrad Corso
07/20/2022, 11:34 PMExecutableElement
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!elihart
03/17/2023, 5:32 PMyigit
03/17/2023, 7:52 PM