Update nscplugin, sbt-scala-native to 0.5.1 and scalacheck to 1.18.0

[satorg]

Should fix #446 and resolve #449.

[satorg]

This task

sbt 'project rootNative' '++ 2.13' Test/nativeLink

is failing with

[error] 'mapSourceURI' is deprecated, it is ignored
[error] one error found
[error] (coreNative / Compile / compileIncremental) Compilation failed
[error] Total time: 2 s, completed Apr 18, 202[4]

but it succeeds on my local machine.

Any idea where can it come from?

[TonioGela]

I was hesitant to manually upgrade to scalacheck 1.18.0 since I expected Scala Steward to open the PR, but strangely its logs mention the update but not open the PR.

The deprecation of mapSourceURI is expected: scala-native/scala-native#3635, but it's not clear what the error refers to.

I'll try to run it locally and see if I debug it.

[satorg]

but strangely its logs mention the update but not open the PR.

Looks like sbt-scala-native and scalacheck have to be updated together in a single PR.
Perhaps, scala-steward is struggling to figure it out.

[satorg]

The deprecation of mapSourceURI is expected

Yeah, I see now, thanks. But I cannot find out where (and whether) it is defined.

I guess it may be related to typelevel/sbt-typelevel#695

[TonioGela]

The deprecation of mapSourceURI is expected

Yeah, I see now, thanks. But I cannot find out where (and whether) it is defined.

I guess it may be related to typelevel/sbt-typelevel#695

It seems that we'll need to manually declare sbt-scala-native in our builds now, as sbt-tl won't include any more, but we're still relying on the last version that includes it and we're also declaring the plugin explicitly.

I still can't see any big difference between this build and the scalacheck one, that successfully compiled with temurin8, scala 2.13 and sn 0.5.x. I'll keep up with the investigation.

[TonioGela]

Btw, in order to publish we'll need to tweak the tlBaseVersion and the tlVersionIntroduced like @mpilquist did in the scalacheck repo

[TonioGela]

So, @keynmol understood that this specific warning is a compiler warning, and we have fatal-warnings enabled in our build (in Scalacheck, it was deactivated). Fatal warnings are turned off by default locally and that's why we aren't seeing it.

We can either wait for a new version of sbt-tl getting published to fix this (it's just a matter of releasing it, the commit is already included in main) or temporary disable fatal-warnings to make it compile again.
I sincerely prefer to wait a few hours to get this fixed for this and all the other repos at once.

[mzuehlke]

The deprecation of mapSourceURI is expected

Yeah, I see now, thanks. But I cannot find out where (and whether) it is defined.
I guess it may be related to typelevel/sbt-typelevel#695

It seems that we'll need to manually declare sbt-scala-native in our builds now, as sbt-tl won't include any more, but we're still relying on the last version that includes it and we're also declaring the plugin explicitly.

I still can't see any big difference between this build and the scalacheck one, that successfully compiled with temurin8, scala 2.13 and sn 0.5.x. I'll keep up with the investigation.

The TypelevelScalaNativeGitHubPlugin gets added automatically (and with it the bad scalacOptions)
You should be able to avoid it by adding:

  .disablePlugins(TypelevelScalaNativeGitHubPlugin)

to your core project in build.sbt.

[satorg]

@mzuehlke , right, we're just thinking that since TypelevelScalaNativeGitHubPlugin is already removed from sbt-typelevel, perhaps it makes sense to await until the next release and fix the issue simply by upgrading to it.

[mzuehlke]

If the release is around the corner, and it looks like it is. Then waiting for is a good idea 👍

[mzuehlke]

The release has landed: https://github.com/typelevel/sbt-typelevel/releases/tag/v0.7.0

[TonioGela]

The release has landed: https://github.com/typelevel/sbt-typelevel/releases/tag/v0.7.0

And I've merged it here in discipline, if we rebase this we should get it green finally

[satorg]

🎉

[satorg]

@mpilquist , it builds now with scala-native v0.5.
However, I'm a bit hesitant to merge it:
I bumped up tlVersionIntroduced to v1.7.0 (which is supposed to be the next one, I guess)
to fix Mima errors, similar to what you did in typelevel/scalacheck#1049.

But you also bumped up tlBaseVersion in there for some reason.
tlBaseVersion does not seem related to Mima checks, does it?
Should I bump tlBaseVersion in here too?

cc @TonioGela @armanbilge (whoever can help please)
Thanks!

[armanbilge]

Should I bump tlBaseVersion in here too?

Yes. This PR includes the change that is causing us to bump the minor. The PR that causes the minor-encoding change should encode that in tlBaseVersion.