Kotlinx.serialization: File names of @serializable classes cause error building multiplatform project.
Task 'compileKotlinIos' fails with :
e: java.util.NoSuchElementException: Sequence contains no element matching the predicate.
at org.jetbrains.kotlinx.serialization.compiler.backend.ir.IrBuilderExtension$DefaultImpls.serializableSyntheticConstructor(GeneratorHelpers.kt:620)
at org.jetbrains.kotlinx.serialization.compiler.backend.ir.SerializableIrGenerator.serializableSyntheticConstructor(SerializableIrGenerator.kt:30)
at org.jetbrains.kotlinx.serialization.compiler.backend.ir.SerializableIrGenerator.generateSuperSerializableCall(SerializableIrGenerator.kt:130)
...
with serializable abstract and inherited classes, but only if the name of the file containing the abstract class comes after the inheriting class alphabetically.
To Reproduce
In file Cabstract.kt:
@Serializable
abstract class Cabstract(
var foo: String
) {
}
in file Binherit.kt:
@Serializable
class Binherit(
var bar: String = ""
) : Cabstract("") {
}
'./gradlew clean build' results in error. Renaming the file 'Binherit.kt' to 'Dinherit.kt' allows the build to complete with no issue.
Expected behavior
Build should run fine regardless of file names.
Environment
- Kotlin version: 1.3.31
- Library version: 0.11.0
- Kotlin platforms: Native
- Gradle version: 5.3.1
- IDE version Android studio 3.3
chrisestesaa01
All 13 comments
Hi,
having the same issue with
kotlin: 1.3.31, serialization: 0.11.0, kotlin: native (iOS)
e: java.util.NoSuchElementException: Sequence contains no element matching the predicate.
at org.jetbrains.kotlinx.serialization.compiler.backend.ir.IrBuilderExtension$DefaultImpls.serializableSyntheticConstructor(GeneratorHelpers.kt:620)
at org.jetbrains.kotlinx.serialization.compiler.backend.ir.SerializableIrGenerator.serializableSyntheticConstructor(SerializableIrGenerator.kt:30)
at org.jetbrains.kotlinx.serialization.compiler.backend.ir.SerializableIrGenerator.generateSuperSerializableCall(SerializableIrGenerator.kt:130)
still investigating what causing this
antanas-arvasevicius
on 31 May 2019
This looks like more of a separate/cross-module compilation issue. It is definitely not related to the class names.
sandwwraith
on 31 May 2019
Are your classes split to main/test modules? Or they're in the same module, but different files? Or in the same file?
sandwwraith
on 31 May 2019
We have common module ios module and android module with separate source, ios module depends on common and implements some exact/actual declarations.
Tests are on the same module with different sourcesets. When running task iosFramework causes this error, dont know if it touches test files
antanas-arvasevicius
on 31 May 2019
So both base class and derived are just in common module?
sandwwraith
on 31 May 2019
Yes everything is inside common module
On Fri, 31 May 2019 at 18:50, Leonid Startsev notifications@github.com
wrote:
So both base class and derived are just in common module?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Kotlin/kotlinx.serialization/issues/472?email_source=notifications&email_token=ABABZHG7T2YOIAKXGDJZV73PYFCODA5CNFSM4HQGUDJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWVTUQI#issuecomment-497760833,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABABZHAJPVZNB5F7X5AROTDPYFCODANCNFSM4HQGUDJA
.
antanas-arvasevicius
on 31 May 2019
Ok, that's fun. It is actually related to names; the problem is the order in which compiler process classes. If file's name with a derived class lexicographically smaller than the file's with a base class, it is processed first and does not see special constructor added by the compiler plugin to the base class. The workaround is to rename files (you don't need to rename classes themselves) or put the whole hierarchy in one file.
sandwwraith
on 3 Jun 2019
So compiler is pretty dumb and don't track usages, but just processes everything lexicographically?
antanas-arvasevicius
on 3 Jun 2019
Reminds me #ifndef #define #endif of C...
antanas-arvasevicius
on 3 Jun 2019
@antanas-arvasevicius This is more of a serialization plugin issue since it uses separate pipeline after main compilation
sandwwraith
on 3 Jun 2019
Is this can be easily fixed? Should we workaround with adding underscores to file names or wait a fix? What's ETA? (week, month, 3months, years)
antanas-arvasevicius
on 3 Jun 2019
@antanas-arvasevicius This will be included in 1.3.40
sandwwraith
on 5 Jun 2019
Thanks!
On Wed, 5 Jun 2019 at 18:33, Leonid Startsev notifications@github.com
wrote:
@antanas-arvasevicius https://github.com/antanas-arvasevicius This will
be included in 1.3.40—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Kotlin/kotlinx.serialization/issues/472?email_source=notifications&email_token=ABABZHAGQN664IH4SAPXL43PY7MD3A5CNFSM4HQGUDJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXADE4I#issuecomment-499135089,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABABZHCX7MCOHXISG5B2EUDPY7MD3ANCNFSM4HQGUDJA
.
antanas-arvasevicius
on 6 Jun 2019
Related issues
raderio
·
3Comments
lonevetad
·
3Comments
erikc5000
·
3Comments
daweedm
·
4Comments
elizarov
·
3Comments
Most helpful comment
Ok, that's fun. It is actually related to names; the problem is the order in which compiler process classes. If file's name with a derived class lexicographically smaller than the file's with a base class, it is processed first and does not see special constructor added by the compiler plugin to the base class. The workaround is to rename files (you don't need to rename classes themselves) or put the whole hierarchy in one file.