Update Kotlin to 1.9.21

[AzimMuradov]

Should fix issues in #373 automatic PR

[AzimMuradov]

Breaking changes:

• Dropping of JS LEGACY (old compiler backend)
• Pimp up Kotlin's language and API versions to the default ("1.4" -> "1.9")

[AzimMuradov]

I'll try to fix the issues causing the warnings. Probably tomorrow or tonight.

[AzimMuradov]

@oshai Is it okay? If yes, can you approve it, please? 😄

[oshai]

Can you please list all changes with an explanation why they are required? (so I can review and add it to the commit comment).

[AzimMuradov]

Can you please list all changes with an explanation why they are required? (so I can review and add it to the commit comment).

Apart from actually moving from Kotlin 1.8.22 to Kotlin 1.9.21, there was some work required for the code to compile:

• Add -Xexpect-actual-classes compiler argument

With Kotlin 1.9.20, KMP is now stable, but expect-actual mechanism for classes is not, hence the need to provide the compiler argument.

• Add ExperimentalForeignApi annotation to cinterop declarations

From https://kotlinlang.org/docs/whatsnew19.html#explicit-c-interoperability-stability-guarantees:

If you want to use C-like foreign APIs such as pointers, you must opt in with @OptIn(ExperimentalForeignApi), otherwise your code won't compile.

• Change kotlin.native.concurrent.* imports to kotlin.concurrent.*

AFAIK, the declarations have been somewhat stabilized and moved to the common location.

• Change JS(BOTH) to JS (same as JS(IR)) in the build script

From https://kotlinlang.org/docs/js-ir-compiler.html:

The old compiler backend has been deprecated since Kotlin 1.8.0. Starting with Kotlin 1.9.0, using compiler types LEGACY or BOTH leads to an error.

• Add kotlin.mpp.applyDefaultHierarchyTemplate=false to gradle.properties

In Kotlin 1.9.20+ there are some improvements to reduce the amount of boilerplate in the target hierarchy: https://kotlinlang.org/docs/whatsnew1920.html#set-up-the-target-hierarchy.

But for an existing project with an established and complex target hierarchy, it's easier to simply opt-out from this feature. That's why I needed to add this option to the properties file.

[oshai]

removing that means only kotlin >= 1.9 is supported, right? if it's possible to keep it explicit it's better.

But a bigger concern is that this forces all users to upgrade to kotlin 1.9, which is not that practical (yet).
If all my assumptions here are correct the best way to move forward is to merge this and create a new major version for the lib, with support for previous version for some time.

[AzimMuradov]

removing that means only kotlin >= 1.9 is supported, right? if it's possible to keep it explicit it's better.

But a bigger concern is that this forces all users to upgrade to kotlin 1.9, which is not that practical (yet).

Sadly, I can't figure out a way with lower api and language versions, but I can set them explicitly.

If all my assumptions here are correct the best way to move forward is to merge this and create a new major version for the lib, with support for previous version for some time.

Agreed, the best way to handle this is to create a new major version and keep support for the previous one for some time.

[oshai]

Thanks! LGTM, other than one comment I added.

[AzimMuradov]

Thanks! I've set the versions explicitly :)

After this PR I'm planning to work on WASM support in the new one. Should I make separate PRs for the other deps updates (like kotlinx libs) and for the actual WASM support, or can I just work on WASM and update the build script at the same time?

[oshai]

Thanks! I've set the versions explicitly :)

After this PR I'm planning to work on WASM support in the new one. Should I make separate PRs for the other deps updates (like kotlinx libs) and for the actual WASM support, or can I just work on WASM and update the build script at the same time?

If the update itself is big (contains code changes etc') I suggest to separate it. Minor changes can be part of the PR.

[oshai]

Thanks! will be released in 6.0.