chore: Add support for Scala Native 0.5.0

[tgodzik]

No description provided.

[tgodzik]

The failing tests are unrelated, I am fixing it I hope in #2295

[sjrd]

Looks good as far as I can tell. Perhaps @kyouko-taiga would like to chime in?

[sjrd]

Seems pretty weird to do something different for Mac than others? Is that something the sbt plugin does as well?

[WojciechMazur]

It's mostly related to LLVM compilation errors happening only on MacOS with LTO=thin
scala-native/scala-native#3833 No idea how to fix it currently.

I have no idea about rest of the codebase and I guess there is no way to configure LTO directly, however we might detect the LTO using env variables? There is a dedicated method to do it, it's used in the sbt plugin.
https://github.com/scala-native/scala-native/blob/4b9f6314a90336d448e0b5cb0fdcb3f122f5c47b/tools/src/main/scala/scala/scalanative/build/Discover.scala#L25

It might be beneficial, because LTO.full can be sometimes slow, so maybe defaulting to LTO.none would be a good choice?
Also, in some configurations LTO=thin might work on MacOS, (see our nightly builds https://github.com/scala-native/scala-native/actions/runs/8226709422/job/22494744082 where we use LLVM linker lld and LLVM distribution of clang instead of the one shipped with MacOS (it does not work on M1 chips though)

[tgodzik]

Hmm... so for now only change in tests? OR default to none, which would be better?

[WojciechMazur]

Defaulting to none is the safest option in my opinion.

[tgodzik]

Switched to none as a default

[WojciechMazur]

Overall looks good to me
I don't know how it my affect the bloop sbt integration but the ScalaNativeKeys were removed from sbt plugin in 0.5.0 (see PR )

[tgodzik]

I don't know how it my affect the bloop sbt integration but the ScalaNativeKeys were removed from sbt plugin in 0.5.0 (see PR )

Och, that would not be easy to replace, we use that heavily 😨 https://github.com/scalacenter/bloop/blob/main/integrations/sbt-bloop/src/main/scala/bloop/integrations/sbt/SbtBloop.scala#L741

Why were they removed? How to get the native configuration now?

[WojciechMazur]

Why were they removed? How to get the native configuration now?

In the whole 0.4.x line these were just a legacy settings and used special order of their initialization to copy their values to nativeConfig task. In all 0.4.x releases and in 0.5.x nativeConfig: Task[build.NativeConfig] is the only effective source of configuration.

https://github.com/scala-native/scala-native/blob/8f1e7d01b82f2fd946fc735461138c791a5e8677/sbt-scala-native/src/main/scala/scala/scalanative/sbtplugin/ScalaNativePlugin.scala#L36-L39

If you have access to scala-native::tools artifact on classpath at that point it should not be a problem to obtain these. Otherwise, we can think about some way to expose nativeConfig in a simple format to bloop

[tgodzik]

In the whole 0.4.x line these were just a legacy settings and used special order of their initialization to copy their values to nativeConfig task. In all 0.4.x releases and in 0.5.x nativeConfig: Task[build.NativeConfig] is the only effective source of configuration.

I will try and do a follow up to handle that.