https://kotlinlang.org logo
#kotlin-native
Title
# kotlin-native
l

Landry Norris

01/27/2023, 4:02 PM
I'm trying to cinterop with a C library where the structs can have a different name for some targets (mostly Foo/Foo_). I figured I could commonize them myself using simple typedefs, but I'm running into what look like some limitations of the K/N compiler.
I’m trying to declare in commonMain
Copy code
expect class Foo: CStructVar {
    val x: Int
    val y: Double
    ...
}
and have
Copy code
actual typealias Foo = cinterop.Foo
and
Copy code
actual typealias Foo = cinterop.Foo_
in the platforms. This should work because the struct members all have the same name/type.
I get an error saying that subclasses of NativePointed can’t have backing fields in my expect class. Is there a way to promise the compiler that these will not be backing fields in the actuals? I tried adding get and set to each field, but it gave the same error.
j

jw

01/27/2023, 4:06 PM
you can search the constant parts of the error message in the jetbrains/kotlin repo to find the error name and suppress it
i do this quite a bit when being a little too clever for the compiler
here's an example of two errors that I've suppressed in my own code with expect/actual
Copy code
@Suppress(
  "ACTUAL_TYPE_ALIAS_NOT_TO_CLASS", // ArrayList itself aliases to j.u.ArrayList on JVM.
  "ACTUAL_WITHOUT_EXPECT", // <https://youtrack.jetbrains.com/issue/KT-37316>
)
internal actual typealias PlatformList<E> = ArrayList<E>
l

Landry Norris

01/27/2023, 4:08 PM
I’ll try this out. I’ve run into similar K/N specific errors before where I know something the compiler doesn’t. It would be nice if it could figure this out itself, though, since that could allow it to warn me if an actual does use a backing field by mistake. Not that typealiasing to a cinterop should ever really have a backing field.
j

jw

01/27/2023, 4:09 PM
Could you use platform-specific .def files and alias the struct name in C so that you don't have to do this in Kotlin?
l

Landry Norris

01/27/2023, 4:10 PM
I believe I could, but unfortunately, one platform has this library in the default platform package, and I couldn’t get the commonizer to commonize my def files with the platform package, even for the structs with the same name.
I tried setting the package to platform.android in my def file, and the commonizer created a klib that commonized the targets, but it only had the package platform.android declaration, no actual classes.
I’ve had the same issue with cocoapods before. It never does a good job of commonizing between different methods of cinterop.
Unfortunately, it appears that the error is in the konan backend, and it looks like suppressable errors are typically FIR or JavaBackend errors. Couldn't find a suppression for it in the source.
3 Views