VirtusLab / scala-cli

Scala CLI is a command-line tool to interact with the Scala language. It lets you compile, run, test, and package your Scala code (and more!)
https://scala-cli.virtuslab.org
Apache License 2.0
541 stars 128 forks source link

Improve Scala compiler settings integration #2867

Open lrytz opened 4 months ago

lrytz commented 4 months ago

Sorry for another ticket like https://github.com/VirtusLab/scala-cli/issues/2779 / https://github.com/VirtusLab/scala-cli/issues/753... I understand there are difficulties how to handle this, but the user experience can probably still be improved.

There are compiler options not forwarded by the compiler, for example

➜ sandbox scala-cli compile --server=false C.scala
-- [E007] Type Mismatch Error: /Users/luc/code/scala/scala13/sandbox/C.scala:2:15
...
  | longer explanation available when compiling with `-explain`
1 error found
Compilation failed

➜ sandbox scala-cli compile --server=false C.scala -explain
Unrecognized argument: -explain

To list all available options, run
  scala-cli compile --help

When a user installs Scala, runs the compiler, and the compiler tells them to add a flag (-explain), they should not need to figure out that they actually need to do -O -explain.

The approach currently is for scala-cli to forward known compiler flags. Would it be possible to pass all unrecognized arguments to the compiler by default (for compile / repl / doc)?

As a backstop, a static hint in the "Unrecognized argument" message could help. If scala-cli compile / repl / doc gets an unrecognized argument, it could suggest "Use -O ${unrecognized} to pass the argument to the Scala compiler".


Another confusing situation is because the compiler is not invoked when there are no souce files. So scala-cli compile -S 2 C.scala -opt:help works, but scala-cli compile -S 2 -opt:help doesn't.


Finally, in Scala 2 at least there are compiler options that support space separated arguments, for example -Vopt _ or -Vprint-args args.txt. The first makes scala-cli hang, the second gives an error message ([error] args.txt: unrecognized source type).

It's again not obvious for the user what's going on.

Gedochao commented 4 months ago

Would it be possible to pass all unrecognized arguments to the compiler by default (for compile / repl / doc)?

I'm not a fan of this, as it may cause unexpected results. Many compiler options take arguments, which then have to be correctly parsed by Scala CLI. I think it would cause more confusion than merit.

A more sustainable solution would be to rely on the Scala compiler Settings API, as implemented in https://github.com/scala/scala3/pull/19766 Doing so is the long-term plan for solving this issue.

I suppose this would only solve options for the Scala 3 compiler (which is the priority). Optimally, Scala 2 could have similar API in the future, which we could use, maybe(thoughts, @lrytz?)

I think we can use this issue to track this, I was hoping to work on this soon.

lrytz commented 4 months ago

I agree the best solution is when scala-cli has a way to talk to the compiler and understand which settings it accepts. That should be doable for Scala 2 as well, I'm happy to help work on that.

If scala-cli becomes default / more prominent before that happens, adding some generic information to scala-cli's Unrecognized argument message seems very helpful.