1.1.0-RC breaks backward compatiblity on JS-IR

[altavir]

Describe the bug

Failure to compile when using JS/common library with serialization 1.0.1 from JS-IR with serialization 1.1.0-RC

Error stack trace

e: java.lang.IllegalStateException: org.jetbrains.kotlin.ir.descriptors.WrappedSimpleFunctionDescriptor@318a95e0 is not bound
	at org.jetbrains.kotlin.ir.descriptors.WrappedDeclarationDescriptor.getOwner(WrappedDescriptors.kt:97)
	at org.jetbrains.kotlin.ir.descriptors.WrappedSimpleFunctionDescriptor.getContainingDeclaration(WrappedDescriptors.kt:373)
	at org.jetbrains.kotlin.resolve.DescriptorUtils.getContainingModuleOrNull(DescriptorUtils.java:200)
	at org.jetbrains.kotlin.resolve.DescriptorUtils.getContainingModule(DescriptorUtils.java:185)
	at org.jetbrains.kotlin.resolve.descriptorUtil.DescriptorUtilsKt.getModule(DescriptorUtils.kt:65)
	at org.jetbrains.kotlin.backend.common.serialization.KotlinIrLinker.findDeserializedDeclarationForSymbol(KotlinIrLinker.kt:543)
	at org.jetbrains.kotlin.backend.common.serialization.KotlinIrLinker.getDeclaration(KotlinIrLinker.kt:586)
	at org.jetbrains.kotlin.ir.util.ExternalDependenciesGeneratorKt.getDeclaration(ExternalDependenciesGenerator.kt:60)
	at org.jetbrains.kotlin.ir.util.ExternalDependenciesGenerator.generateUnboundSymbolsAsDependencies(ExternalDependenciesGenerator.kt:50)
	at org.jetbrains.kotlin.ir.backend.js.CompilerKt.compile(compiler.kt:79)
	at org.jetbrains.kotlin.ir.backend.js.CompilerKt.compile$default(compiler.kt:36)
	at org.jetbrains.kotlin.cli.js.K2JsIrCompiler.doExecute(K2JsIrCompiler.kt:254)
	at org.jetbrains.kotlin.cli.js.K2JSCompiler.doExecute(K2JSCompiler.java:181)
	at org.jetbrains.kotlin.cli.js.K2JSCompiler.doExecute(K2JSCompiler.java:74)
	at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:88)
	at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:44)
	at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:98)
	at org.jetbrains.kotlin.daemon.CompileServiceImpl.compile(CompileServiceImpl.kt:1575)
	at jdk.internal.reflect.GeneratedMethodAccessor101.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
	at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
	at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:676)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)

Serialization is not mentioned in the stacktrace. But switching the serialization version obviously triggers the behavior. One can reproduce it here by removing ("1.0.1") and rolling back to plugin - default 1.1.0-RC. The library relies on xmlutil 0.80.1, which uses older serialization. With 1.0.1 it compiles, but could not be consumed in project with newer version.

Environment

• Kotlin version: 1.4.30

[altavir]

I tried to find a workaround for that but seems to be impossible. The only way is to recompile all dependencies with 1.1.0

[altavir]

Seems to be a blocker for release :(. I can't move forward because new codebase reliese on 1.4.30 and serialization 1.1.0 but xmlutil is still on 1.0.1 and there are no ways to make them work together.

[pdvrieze]

I've had a quick look, I'll have to figure out how to make inline classes work properly. There is nice user documentation, but not for format writers. I'll manage though ;-), but just using the same decoder/encoder clearly doesn't work.

[pdvrieze]

Another issue seems to be that I can't get 1.4.30 to actually generate proper code for inline classes (to test it all)

[sandwwraith]

I've dig into the problem for a bit and found out that the unbound symbol in question is an overload of decodeNullableSerializableElement — and indeed, it was deleted in this release (#1260), so this is kinda a backwards-incompatible change.

However, we intended to delete this function anyway and it was deprecated since 1.0 (or even earlier) so it looks like the root of the problem is that one of the dependencies or the project itself still used this deprecated function. I've searched in the xmlutil library, but haven't found any usages of deprecated three-argument overload (although helpers.kt might look suspicious, but it also qualifies for non-deprecated overload with default arg). Unfortunately, I was unable to track in the debugger this unbound symbol further and find its origin.

[sandwwraith]

@pdvrieze What do you mean by that? Note, inline classes in serialization work only with IR compilers

[pdvrieze]

@pdvrieze What do you mean by that? Note, inline classes in serialization work only with IR compilers

I found that, although the error message could be more helpful.

[pdvrieze]

@sandwwraith I've enabled usage of IR on test suite compilations. That fixes the inline issue. After implementing the inline functions the library compiles correctly (and I'm also correcting the helpers function to explicitly call the 4 arg version). The helpes file mentioned is part of the util library that contains various bits and bops to help with serialization, but which isn't required for xml serialization itself.

[ivakub]

https://youtrack.jetbrains.com/issue/KT-45306

[brunnobraga]

I'm facing a similar issue, but compiling for iOS. When upgrading to 1.1.0 and running packForXcode task I get the following:

> Task :shared:linkDebugFrameworkIos
e: Compilation failed: Unbound symbols not allowed

Unbound public symbol for public kotlinx.serialization.json.internal/StreamingJsonDecoder.decodeNullableSerializableElement|7091057077819363828[0] public kotlinx.serialization.json.internal/StreamingJsonDecoder.decodeNullableSerializableElement|7091057077819363828[0]
Unbound public symbol for public kotlinx.serialization.json.internal/StreamingJsonDecoder.decodeSerializableElement|8042733237355806987[0] public kotlinx.serialization.json.internal/StreamingJsonDecoder.decodeSerializableElement|8042733237355806987[0]
Unbound public symbol for public kotlinx.serialization.internal/NamedValueDecoder.decodeNullableSerializableElement|7091057077819363828[0] public kotlinx.serialization.internal/NamedValueDecoder.decodeNullableSerializableElement|7091057077819363828[0]
Unbound public symbol for public kotlinx.serialization.json/JsonDecoder.decodeNullableSerializableElement|7091057077819363828[0] public kotlinx.serialization.json/JsonDecoder.decodeNullableSerializableElement|7091057077819363828[0]
Unbound public symbol for public kotlinx.serialization.internal/NamedValueDecoder.decodeSerializableElement|8042733237355806987[0] public kotlinx.serialization.internal/NamedValueDecoder.decodeSerializableElement|8042733237355806987[0]
Unbound public symbol for public kotlinx.serialization.json/JsonDecoder.decodeSerializableElement|8042733237355806987[0] public kotlinx.serialization.json/JsonDecoder.decodeSerializableElement|8042733237355806987[0]

From what I could understand this is the same symbol, right?

[sandwwraith]

@brunnobraga Yes, it is

[KevinBassaDevelopment]

We have the same issue when compiling on iOS.
Its not possible to compile our project on iOS with serializer version 1.1.0.

Tested on version: 1.1.0.
It is working when using 1.0.1.

Error message:

Execution failed for task '😒hared:linkDebugFrameworkIosX64'.
> Compilation finished with errors
Unbound public symbol for public kotlinx.serialization.json/JsonDecoder.decodeNullableSerializableElement|7091057077819363828[0] public kotlinx.serialization.json/JsonDecoder.decodeNullableSerializableElement|7091057077819363828[0]
Unbound public symbol for public kotlinx.serialization.json/JsonDecoder.decodeSerializableElement|8042733237355806987[0] public kotlinx.serialization.json/JsonDecoder.decodeSerializableElement|8042733237355806987[0]
Unbound public symbol for public kotlinx.serialization.json.internal/StreamingJsonDecoder.decodeNullableSerializableElement|7091057077819363828[0] public kotlinx.serialization.json.internal/StreamingJsonDecoder.decodeNullableSerializableElement|7091057077819363828[0]
Unbound public symbol for public kotlinx.serialization.json.internal/StreamingJsonDecoder.decodeSerializableElement|8042733237355806987[0] public kotlinx.serialization.json.internal/StreamingJsonDecoder.decodeSerializableElement|8042733237355806987[0]
Unbound public symbol for public kotlinx.serialization.internal/NamedValueDecoder.decodeNullableSerializableElement|7091057077819363828[0] public kotlinx.serialization.internal/NamedValueDecoder.decodeNullableSerializableElement|7091057077819363828[0]
Unbound public symbol for public kotlinx.serialization.internal/NamedValueDecoder.decodeSerializableElement|8042733237355806987[0] public kotlinx.serialization.internal/NamedValueDecoder.decodeSerializableElement|8042733237355806987[0]

[sandwwraith]

Unfortunately, we can't do much at this point since 1.0.1 and 1.1.0 are already released. The only recommendation to fix this is to make sure that you have only one serialization version in your transitive dependencies (i.e. update libraries versions you use so they also depend on serialization 1.1.0)

From our side, we'll try our best to prevent such a situation from happening again