Would it be worth a bug report to make `SirUnsuppo...

# swift-export

[Zac Sweers]

Would it be worth a bug report to make SirUnsupportedType errors report more information? It's currently pretty opaque and inactionable

[Zac Sweers]

Some other noise higher up in the logs too

[Rick Clephas]

Do you have an example of some Kotlin code? Or what you would expect in Swift?

[Rick Clephas]

(working on something closely related)

[Zac Sweers]

tbh I don't really know where to look to start. Here's a branch in circuit: https://github.com/slackhq/circuit/tree/z/test24dev

[Zac Sweers]

where this is the commit https://github.com/slackhq/circuit/commit/1c0d6930c2c0d94e626d461aadf118881820da56

[Zac Sweers]

sample I was testing is samplescounter

[Rick Clephas]

Ah got it. I thought you had some specific Kotlin code that resulted in a SirUnsupportedType

[Zac Sweers]

I appear to!

[Zac Sweers]

I just don't know which kotlin code 😅

[Rick Clephas]

Ah w8 I see the exception now. Yeah an issue would be great.
Should definitely investigate. AFAIK it's not supposed to crash like this 😇

[Zac Sweers]

I'll file one later!

[Zac Sweers]

KT-85624 SirUnsupportedType error is vague/inactionable

[Artem Olkov]

Hello there, thanks for the report 🙂

> Some other noise higher up in the logs too
That's a known problem, please follow https://youtrack.jetbrains.com/issue/KT-84410 . TLDR: we are aiming to fix this with 2.4.20. Hopefully...

[Artem Olkov]

As for the actual report - I've encountered this error only once in my testing in the last month - please see https://youtrack.jetbrains.com/issue/KT-85380

The first build containing the fix is 8547. Do you mind trying it out?

[Zac Sweers]

nice, it does appear to get past that error now, though not able to meaningfully proceed with the build yet due to other issues. Namely it doesn't propagate opt-ins for experimental APIs (so generated swift export files referencing experimental APIs fail to compile) and this error that I can't quite figure out

Showing Recent Issues
/Users/zacsweers/dev/kotlin/contributing/circuit/samples/counter/apps/iosApp/  /Users/zacsweers/dev/kotlin/contributing/circuit/samples/counter/build/SPMPackage/iosSimulatorArm64/Debug/Sources/OrgJetbrainsComposeUiUiGraphics/OrgJetbrainsComposeUiUiGraphics.swift:2364:21: type member must not be named 'Type', since it would conflict with the 'foo.Type' expression

          public enum Type: KotlinRuntimeSupport._KotlinBridgeable, Swift.CaseIterable, Swift.LosslessStringConvertible, Swift.RawRepresentable {

                      ^~~~

                      `Type`

It's not a type I own, but appears to imply that any library that has a class called Type is wholly incompatible with swift export then? In this case this API coming from compose UI

[Artem Olkov]

it doesn't propagate opt-ins for experimental APIs

Yes, support for that was merged on the last week - https://github.com/JetBrains/kotlin/pull/5813

This will be included in 2.4.20 release 🙂 First dev build is dev-371

type member must not be named 'Type', since it would conflict with the 'foo.Type' expression

Oh, that's a fun bug. I will file a bug for that.

On that note - Why do you export ComposeUI? I always assumed that this is not a library that would be useful on the side of iOS. But I'm curious about your usecase.

[Artem Olkov]

I assume it's this Type

[Artem Olkov]

KT-85660

[Zac Sweers]

Why do you export ComposeUI?

I don't! At least not as far as I know? This is all there is in the swift export block. The closest guess I have for this is that it's an api dependency in commonMain, which does make sense for this library

[Zac Sweers]

doesn't look lke KT-85660 is public

[Artem Olkov]

Oh, sorry about that, published 🙂

[Artem Olkov]

At least not as far as I know?

Yeah, that can happen, as we do transitive export - if a part of your public API requires some part of another libraries public API - this part will also be exported. And everything that is needed by that part.

As an example

// module foo

class Foo // will be exported

class Bar { // will be exported
  fun foo(): Foo = TODO() // forces export of Foo
}

class Zar // will not be exported

// module shared // exported by swift export

fun bar(): Bar = TODO() // forces export of Bar

If my assumption about what Type is exported in your case - you either have a PathSegment as a part of your public API, or some other class from ui-graphics is a part of your public API and that class transitively exports PathSegment.

in future versions of swift export we plan to release an exclusion from this algorithm for a particular module, but I don't have any public timelines for that 😞

I think that in your case it's the following:
1. Remove is a public value of type ImageVector - link
2. ImageVector can be found here
3. ImageVector starts pulling ui-graphics to the public api surface uncontrollably and leads to this error.
At least at first glance it's the only usage of this library in a public api in your sample, but maybe I don't see everything

[Zac Sweers]

gotcha, yeah I'm not sure offhand what to do about that. The API I need to expose to swift is limited but the API to other consumers can be broader. Would the recommendation be to explicitly define dependency as implementation in the iOS sourceset and api in all the others?

[Artem Olkov]

The API I need to expose to swift is limited but the API to other consumers can be broader

For that there is a HiddenFromObjC annotation, that is also supported by Swift Export 🙂

[Zac Sweers]

ah no I meant the underlying dependency at the build level

[Artem Olkov]

plicitly define dependency as implementation in

Nope, that has zero effect in the export config.

[Artem Olkov]

ah no I meant the underlying dependency at the build level

And again - we will provide an API for such cases, but we do not have a public timeline for that 😞

[Zac Sweers]

is there an issue I could follow?

[Artem Olkov]

Let me create a public one 🙂

[Artem Olkov]

KT-85687

[Artem Olkov]

It's not much but it's an honest work kodee intensifies

[Zac Sweers]

appreciated!