Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add integration tests to check each supported scalac option against each supported scalac version #7

Open
satorg opened this issue Sep 14, 2022 · 4 comments

Comments

@satorg
Copy link
Contributor

satorg commented Sep 14, 2022

This is a call-out to trigger a discussion rather than an issue itself.

We could create an IntegrationTest configuration and add tests that would verify whether a certain scalac option is really supported for a specific scalac version.

Checking it by hand is quite boring and unreliable and it would be nice to automate it somehow.
A straightforward solution that comes to mind is using scala-cli for each option and every scala version the project supposed to support:

$ scala-cli compile -S 2.12.12 -O -Xlint:deprecation -- empty.scala
Compiling project (Scala 2.12.12, JVM)
Error: 'deprecation' is not a valid choice for '-Xlint'
Compiled project (Scala 2.12.12, JVM)

whereas

$ scala-cli compile -S 2.12.13 -O -Xlint:deprecation -- empty.scala

compiles without errors.

So would it be possible to employ scala-cli for integration tests in the project and does it look reasonable overall?

See also #5 for a related discussion.

@armanbilge
Copy link
Member

👍 to the idea. But I propose we just do it with scalac; scala-cli is an extra dependency to juggle with its own complications (like that it requires JDK 17 ....)

@satorg satorg changed the title Engage scala-cli for integration tests Add integration tests to check each supported scalac option against each supported scalac version Sep 14, 2022
@TonioGela
Copy link
Member

TonioGela commented Mar 20, 2024

👍 to the idea. But I propose we just do it with scalac; scala-cli is an extra dependency to juggle with its own complications (like that it requires JDK 17 ....)

Random thoughts: with coursier you can install a specific scalac version with cs install scalafmt:2.4.2. I bet itr can be used as a dependency very much we do in the tests of the typelevel toolkit, and with that we could theoretically download and install specific scalac version to use, with the proper flags, against a specific scala file.

Another chance would be leveraging sbt scripted tests maybe?

@armanbilge
Copy link
Member

scalac itself is a very ordinary dependency :) No need to fuss with coursier. We can just add every version of scalac to the build and then invoke them in isolated classloaders or something.

@TonioGela
Copy link
Member

scalac itself is a very ordinary dependency :) No need to fuss with coursier. We can just add every version of scalac to the build and then invoke them in isolated classloaders or something.

Okay, I'll sort out something then :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants