Kotlin/Native compiler crashes, ‘Expecting descriptor for SuspendCallback.Companion.Adapter’ #751
Labels
Comments
|
I posted an FYI on the Kotlin slack. |
|
So for Compose we have to put this cacheKind=none Gradle property to make it work for native and JetBrains couldn't remember why and didn't remember exactly what it did. Maybe try adding that? See Redwood or Molecule repos for the exact property. |
|
Oh but my point is when you forget to include that property it manifests in errors exactly like this one. |
|
Holy cow, that worked. I’m impressed, delighted, horrified, and grateful. Thanks homie! |
|
No further action on this in the Zipline project. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I’ve been puzzling over this crash for almost 24 hours...
Problem: Generated Code Can’t Reliably See Generated Declarations in Kotlin/Native
When generated code in one module refers to generated code in another module, that can cause exceptions when deserializing the two modules together.
java.lang.IllegalStateException: Expecting descriptor for app.cash.zipline.internal.bridge/SuspendCallback.Companion.Adapter|null[0])
Exploration of the cause
I’ve learned that the Kotlin/Native compiler is working against us somewhat. Here’s what it does:
To confirm this, set these breakpoints:
SuspendCallback. (Breakpoint condition isname.asString().contains("Callback").)SuspendCallback. (Breakpoint condition is"Callback" in declaration.name.asString())SuspendCallback. (Breakpoint condition is"SuspendCallback" in classDescriptor.name.asString())Next, execute
zipline:macosArm64Testin a debugger. This is easy enough to do in the Gradle sidebar.The breakpoints hit in the order above. On the first breakpoint, the
unsubstitutedInnerClassesScope.invoke()function does not include aCompanionmember because it won’t be generated until breakpoint 2. That means the companion remains missing when serializing the Klib in step 3.This is a problem because our Kotlin compiler-generated code (the nested
CompanionandAdapter) refers to other generated code to lookup required serializers. But since the klib doesn’t include these declarations, compilation crashes with the exception above.Mitigation for Zipline
Referring to generated code from generated code is super convenient! And losing that is very annoying for our model.
But I think I can mitigate by looking up serializers with contextual serialization, rather than having them available statically. This will change generated code from emitting something like this:
To emitting something like this:
to this:
We already do this for certain types, so it’s not a particularly big change. The biggest drawback is we’ll need to decide which adapters to preregister as available contextual ones. Hopefully not everything.
The text was updated successfully, but these errors were encountered: