Improve Scala compiler settings integration

[lrytz]

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]

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]

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.