I'm trying to cinterop with a C library where the structs can have a different name for some targets...

# kotlin-native

[Landry Norris]

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.

[Landry Norris]

I’m trying to declare in commonMain

expect class Foo: CStructVar {
    val x: Int
    val y: Double
    ...
}

and have

actual typealias Foo = cinterop.Foo

and

actual typealias Foo = cinterop.Foo_

in the platforms. This should work because the struct members all have the same name/type.

[Landry Norris]

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.

[jw]

you can search the constant parts of the error message in the jetbrains/kotlin repo to find the error name and suppress it

[jw]

i do this quite a bit when being a little too clever for the compiler

[jw]

here's an example of two errors that I've suppressed in my own code with expect/actual

@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>

[Landry Norris]

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.

[jw]

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?

[Landry Norris]

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.

[Landry Norris]

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.

[Landry Norris]

I’ve had the same issue with cocoapods before. It never does a good job of commonizing between different methods of cinterop.

[Landry Norris]

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.