If invalid scalacOptions are specified, a clear warning should be printed or compilation should fail.

[ALPSMAC]

• I've read the CONTRIBUTING guidelines

steps

Create a build file that looks something like this:

lazy val root = (project in file(".")).settings(
  //whatever other options you need,
  scalacOptions += "Ypartial-unification" //note the missing '-'!!! 
)

Do something in your Scala code that requires the partial-unification fix to be on (in our case we were using for-comprehension syntax with the Fetch library (https://github.com/47deg/fetch) ).

Then try:

sbt compile

problem

scalac (as invoked by SBT) bombs with a cryptic compile error when partial-unification is required in your code base.

Observed in SBT 0.13.15... haven't tried it in 1.x yet.

expectation

When you run scalac by hand and pass an invalid flag (like Ypartial-unification - note the missing -) it bombs right away telling you you've done something silly with command line arguments. This is a helpful error message and you can pretty quickly figure out what you did wrong.

SBT should at minimum elicit the same error message from scalac. Instead it appears to be silently dropping the invalid scalac option and merrily compiling without the clearly intended command-line argument (i.e. -Ypartial-unification - note the -).

Instead of silently dropping invalid compiler options SBT should fail the build or at least print a clear warning message.

It's possible I'm being silly here and such a warning was printed and I missed it (or maybe I could have turned up logging somehow to see it or something)... but I wasted 6 hours trying to track this bug down and it came down to a missing -... one of the first things I did was check for the partial-unification flag, but I missed that the - was missing!

I verified that scalac itself would have been smart enough to tell you when you make a mistake like this, so by process of elimination I'm assuming that it's probably an SBT issue (which I know can be dangerous, so feel free to tell me this isn't SBT's problem :-) ).

Arguably this could be called an improvement but this seems more like a bug to me since it appears to be contrary to the observed behavior of scalac itself.

notes

sbt version: 0.13.15
Not sure if it applies to 1.x or not.

[eed3si9n]

@ALPSMAC Thanks for the report. I am tagging this "Needinfo", for looking into where the difference in the behavior is coming from.
Also, if I recall correctly, passing bogus flags into Scala compiler normally results to an error message. Otherwise, passing flags would be much easier since some flags are supported only by some Scala versions. Maybe there's something about -?

[eed3si9n]

I am closing this due to inactivity.