Found in #126. With JsonPlugin, any module containing a u128 or i128 field fails to compile:
e: Serializer has not been found for type 'BigInteger'. To use context serializer as fallback, explicitly annotate type or property with @Contextual
Cause. The JSON plugin binds its BigIntegerSerializer through a same-file alias emitted from module_helpers (json/kotlin.rs, FEATURE_BIGINT):
typealias BigInteger = @Serializable(with = BigIntegerSerializer::class) BigInteger
but write_module_header (kotlin/emitter/mod.rs, around the Feature::BigInt check) unconditionally writes import java.math.BigInteger for the same modules. In Kotlin an explicit import outranks a same-package declaration, so every BigInteger in the file resolves to java.math.BigInteger and the alias, with its serializer annotation, is never used. The alias is also self-referential: its right-hand side is the bare BigInteger, which only means anything because of that import.
Verified fix shape. Qualifying the alias's right-hand side (... java.math.BigInteger, as the UUID alias already does) and dropping the emitter's import when the JSON plugin is active makes the whole main fixture compile. Qualifying the right-hand side alone is not enough because the import still wins. The clean version needs the emitter to know that a plugin is supplying the alias, or the import to move into the bincode plugin's imports() where it is actually needed.
The Kotlin compile test currently strips 128-bit fields from the main fixture (remove_128_bit_fields in tests/kotlin_generation.rs); that workaround should go once this is fixed.
Found in #126. With
JsonPlugin, any module containing au128ori128field fails to compile:Cause. The JSON plugin binds its
BigIntegerSerializerthrough a same-file alias emitted frommodule_helpers(json/kotlin.rs,FEATURE_BIGINT):but
write_module_header(kotlin/emitter/mod.rs, around theFeature::BigIntcheck) unconditionally writesimport java.math.BigIntegerfor the same modules. In Kotlin an explicit import outranks a same-package declaration, so everyBigIntegerin the file resolves tojava.math.BigIntegerand the alias, with its serializer annotation, is never used. The alias is also self-referential: its right-hand side is the bareBigInteger, which only means anything because of that import.Verified fix shape. Qualifying the alias's right-hand side (
... java.math.BigInteger, as theUUIDalias already does) and dropping the emitter's import when the JSON plugin is active makes the whole main fixture compile. Qualifying the right-hand side alone is not enough because the import still wins. The clean version needs the emitter to know that a plugin is supplying the alias, or the import to move into the bincode plugin'simports()where it is actually needed.The Kotlin compile test currently strips 128-bit fields from the main fixture (
remove_128_bit_fieldsintests/kotlin_generation.rs); that workaround should go once this is fixed.