Quantcast

Option to treat warnings as errors?

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Option to treat warnings as errors?

Paul Butcher
I've just discovered that scalac has no option to treat warnings as errors.

I guess it shouldn't come as a surprise, given that neither does javac. Or actually, after a bit of digging, it turns out that it does but it's undocumented:

http://bugs.sun.com/view_bug.do?bug_id=6595666

Coming as I do from the C/C++ world, where this is the very first compiler option I switch on, I'm kinda amazed that the Java (and apparently Scala) communities take warnings so lightly!

Is there any reason why such an option couldn't be added, or would be undesirable?

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: [hidden email]
AIM: paulrabutcher
Skype: paulrabutcher

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Option to treat warnings as errors?

Nils Kilden-Pedersen
Xfatal-warnings?

On Sun, Apr 25, 2010 at 4:41 PM, Paul Butcher <[hidden email]> wrote:
I've just discovered that scalac has no option to treat warnings as errors.

I guess it shouldn't come as a surprise, given that neither does javac. Or actually, after a bit of digging, it turns out that it does but it's undocumented:

http://bugs.sun.com/view_bug.do?bug_id=6595666

Coming as I do from the C/C++ world, where this is the very first compiler option I switch on, I'm kinda amazed that the Java (and apparently Scala) communities take warnings so lightly!

Is there any reason why such an option couldn't be added, or would be undesirable?

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: [hidden email]
AIM: paulrabutcher
Skype: paulrabutcher


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Option to treat warnings as errors?

Paul Butcher
On 25 Apr 2010, at 22:57, Nils Kilden-Pedersen wrote:
> Xfatal-warnings?


Aha! Thanks for the pointer - committed a whole 9 days ago :-)

It does lead me to wonder which other options I might want to use. Some googling has turned up -Xcheckinit and -Xwarninit, for example, both of which appear to have been supported for some time, but neither of which are mentioned in "man scalac". Is there a definitive list anywhere?

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: [hidden email]
AIM: paulrabutcher
Skype: paulrabutcher

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Option to treat warnings as errors?

Daniel Sobral
C:\Users\Daniel\Documents\Scala\Programas>scalac
Usage: scalac <options> <source files>
where possible standard options include:
  -X                             Print a synopsis of advanced options
  -bootclasspath <path>          Override location of bootstrap class files
  <etc>

What else do you need?

On Sun, Apr 25, 2010 at 7:23 PM, Paul Butcher <[hidden email]> wrote:
On 25 Apr 2010, at 22:57, Nils Kilden-Pedersen wrote:
> Xfatal-warnings?


Aha! Thanks for the pointer - committed a whole 9 days ago :-)

It does lead me to wonder which other options I might want to use. Some googling has turned up -Xcheckinit and -Xwarninit, for example, both of which appear to have been supported for some time, but neither of which are mentioned in "man scalac". Is there a definitive list anywhere?

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: [hidden email]
AIM: paulrabutcher
Skype: paulrabutcher




--
Daniel C. Sobral

I travel to the future all the time.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Option to treat warnings as errors?

Paul Butcher
On 26 Apr 2010, at 00:12, Daniel Sobral wrote:
>   -X                             Print a synopsis of advanced options
>   -bootclasspath <path>          Override location of bootstrap class files
>   <etc>
>
> What else do you need?

Forgive me - I was looking at "man scalac" which doesn't mention the -X option at all. And which does have a list of "Advanced Options", but which doesn't include all of them.

It's good to know that the compiler itself is more helpful, but perhaps the man pages could be too? Or at least perhaps they could include a warning that they're incomplete? It might be naive of me, but I assumed that if it wasn't mentioned in the manual page, it wasn't documented - especially when various google searches of the form "scalac Xcheckinit", "scalac options", "scalac advanced options" etc. didn't find anything at all helpful.

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: [hidden email]
AIM: paulrabutcher
Skype: paulrabutcher

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Option to treat warnings as errors?

Paul Phillips-3
In reply to this post by Paul Butcher
On Sun, Apr 25, 2010 at 11:23:24PM +0100, Paul Butcher wrote:
> Aha! Thanks for the pointer - committed a whole 9 days ago :-)

It is much older than that.  Nine days ago it moved from
-Yfatal-warnings to -Xfatal-warnings.

--
Paul Phillips      | A national political campaign is better than the
In Theory          | best circus ever heard of, with a mass baptism and
Empiricist         | a couple of hangings thrown in.
i pull his palp!   |     -- H. L. Mencken
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Option to treat warnings as errors?

Daniel Sobral
In reply to this post by Paul Butcher
As a side note, C, and, to the extent that backward compatibility is possible, C++ as well, are much more lenient about a lot of things, which result in a lot of code that is technically correct but probably wrong. This is why there's a lot of work in producing warnings, and why warning-free programs are desirable.

Java and Scala are more strict, making warnings less numerous -- though certainly not less useful. Warnings such as non-exaustive match and type erasure have been strongly correlated with errors in my own code -- though the latter is not always an error, and it is very difficult to get rid of.

On Sun, Apr 25, 2010 at 6:41 PM, Paul Butcher <[hidden email]> wrote:
I've just discovered that scalac has no option to treat warnings as errors.

I guess it shouldn't come as a surprise, given that neither does javac. Or actually, after a bit of digging, it turns out that it does but it's undocumented:

http://bugs.sun.com/view_bug.do?bug_id=6595666

Coming as I do from the C/C++ world, where this is the very first compiler option I switch on, I'm kinda amazed that the Java (and apparently Scala) communities take warnings so lightly!

Is there any reason why such an option couldn't be added, or would be undesirable?

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: [hidden email]
AIM: paulrabutcher
Skype: paulrabutcher




--
Daniel C. Sobral

I travel to the future all the time.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Option to treat warnings as errors?

Randall R Schulz-2
On Sunday April 25 2010, Daniel Sobral wrote:
> As a side note, C, and, to the extent that backward compatibility is
> possible, C++ as well, are much more lenient about a lot of things,
> which result in a lot of code that is technically correct but
> probably wrong. This is why there's a lot of work in producing
> warnings, and why warning-free programs are desirable.

Further aside: http://lambda-the-ultimate.org/node/3915

Also, I'd say those programs are not "technically correct but probably
wrong," they're actually wrong but in ways that remain latent. Latent
until they're not, anyway.


> ...


Randall Schulz
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Option to treat warnings as errors?

Paul Butcher
In reply to this post by Daniel Sobral
On 26 Apr 2010, at 04:31, Daniel Sobral wrote:
> Warnings such as non-exaustive match and type erasure have been strongly correlated with errors in my own code -- though the latter is not always an error, and it is very difficult to get rid of.

I'd be very interested to see an example of a warning that is generated for correct code and which can't easily be avoided. I ask because it's exactly this kind of thing that I'm battling with at the moment (a type erasure warning). Now that I've worked out that I'm getting the warning at all, that is - given that I initially missed it in the slew of output that sbt generates (which is what prompted this discussion in the first place :-)

In my particular case, I think that I've decided to sidestep the issue by designing the code in a different way entirely. But it would be interesting to see an example of "good" code that still generates a warning which can't be avoided without making the code "worse".

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: [hidden email]
AIM: paulrabutcher
Skype: paulrabutcher

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Option to treat warnings as errors?

Daniel Sobral
The one I can't easily get around is the erasure in pattern matching. Something like this:

x match { case l: List[String] => /* ... */ }

This produces a warning because the type parameter can't be verified, and, indeed, it is often an error. However, sometimes you do know what the the type parameter is -- in such situations, you can either live with the warning or apply .asInstanceOf to l after matching it against List[_]. You cannot, however, get rid of the warning.

I think there's another situation related to matches -- and which can be ridden of by annotations -- but I can't recall it right now.

On Mon, Apr 26, 2010 at 6:18 AM, Paul Butcher <[hidden email]> wrote:
On 26 Apr 2010, at 04:31, Daniel Sobral wrote:
> Warnings such as non-exaustive match and type erasure have been strongly correlated with errors in my own code -- though the latter is not always an error, and it is very difficult to get rid of.

I'd be very interested to see an example of a warning that is generated for correct code and which can't easily be avoided. I ask because it's exactly this kind of thing that I'm battling with at the moment (a type erasure warning). Now that I've worked out that I'm getting the warning at all, that is - given that I initially missed it in the slew of output that sbt generates (which is what prompted this discussion in the first place :-)

In my particular case, I think that I've decided to sidestep the issue by designing the code in a different way entirely. But it would be interesting to see an example of "good" code that still generates a warning which can't be avoided without making the code "worse".

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: [hidden email]
AIM: paulrabutcher
Skype: paulrabutcher




--
Daniel C. Sobral

I travel to the future all the time.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Option to treat warnings as errors?

Rex Kerr-2
On Mon, Apr 26, 2010 at 3:08 PM, Daniel Sobral <[hidden email]> wrote:
The one I can't easily get around is the erasure in pattern matching. Something like this:

x match { case l: List[String] => /* ... */ }

This produces a warning because the type parameter can't be verified, and, indeed, it is often an error. However, sometimes you do know what the the type parameter is -- in such situations, you can either live with the warning or apply .asInstanceOf to l after matching it against List[_].

The typical case (x: Any) should produce a warning, and since asInstanceOf doesn't throw an error, if you check that every item contained is in fact a string:
  def getListString2(a: Any): Option[List[String]] = a match {
    case l: List[_] if (l.forall(_.isInstanceOf[String])) => Some(l.asInstanceOf[List[String]])
    case _ => None
  }
then you really are safe given List's immutability (and I don't get any warnings--though I also don't get warnings when using asInstanceOf unsafely).

There is a case that is arguably a compiler enhancement target:
  def getSeqIsList(ss: Seq[String]): Option[List[String]] = ss match {
    case l: List[String] => Some(l)
    case _ => None
  }
This produces a warning, even though there is no way that you could get a Seq[String] that is a List[_] but cannot be considered a List[String].

But isn't the deeper problem that we widen to "Any" or "AnyRef" when we really only want to widen to "List[String] | Array[Byte] | Double" or something like that?  If type unions like this were commonplace, most of the warnings would justifiably go away.

  --Rex

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Option to treat warnings as errors?

Daniel Sobral
I'm not complaining about the warning. I'm only saying there's no way to get _rid_ of it, which leaves me no choice but use asInstanceOf or keep the warning.

On Mon, Apr 26, 2010 at 4:32 PM, Rex Kerr <[hidden email]> wrote:
On Mon, Apr 26, 2010 at 3:08 PM, Daniel Sobral <[hidden email]> wrote:
The one I can't easily get around is the erasure in pattern matching. Something like this:

x match { case l: List[String] => /* ... */ }

This produces a warning because the type parameter can't be verified, and, indeed, it is often an error. However, sometimes you do know what the the type parameter is -- in such situations, you can either live with the warning or apply .asInstanceOf to l after matching it against List[_].

The typical case (x: Any) should produce a warning, and since asInstanceOf doesn't throw an error, if you check that every item contained is in fact a string:
  def getListString2(a: Any): Option[List[String]] = a match {
    case l: List[_] if (l.forall(_.isInstanceOf[String])) => Some(l.asInstanceOf[List[String]])
    case _ => None
  }
then you really are safe given List's immutability (and I don't get any warnings--though I also don't get warnings when using asInstanceOf unsafely).

There is a case that is arguably a compiler enhancement target:
  def getSeqIsList(ss: Seq[String]): Option[List[String]] = ss match {
    case l: List[String] => Some(l)
    case _ => None
  }
This produces a warning, even though there is no way that you could get a Seq[String] that is a List[_] but cannot be considered a List[String].

But isn't the deeper problem that we widen to "Any" or "AnyRef" when we really only want to widen to "List[String] | Array[Byte] | Double" or something like that?  If type unions like this were commonplace, most of the warnings would justifiably go away.

  --Rex




--
Daniel C. Sobral

I travel to the future all the time.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Option to treat warnings as errors?

Rex Kerr-2
On Mon, Apr 26, 2010 at 3:46 PM, Daniel Sobral <[hidden email]> wrote:
I'm not complaining about the warning. I'm only saying there's no way to get _rid_ of it, which leaves me no choice but use asInstanceOf or keep the warning.

There is a way to get rid of it (but not only it): -nowarn

And asInstanceOf is probably the better pattern to use anyway, since
  x match {
    case ls: List[String] => // ...
    case lf: List[Float] => // ...
    ...
  }
is a tempting error to make, and asInstanceOf keeps one from a suggestive but misleading match statement.

  --Rex

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Option to treat warnings as errors?

Paul Phillips-3
In reply to this post by Paul Butcher
On Mon, Apr 26, 2010 at 10:18:30AM +0100, Paul Butcher wrote:
> I'd be very interested to see an example of a warning that is
> generated for correct code and which can't easily be avoided.

From my branch of configgy:

  for ((key: String, cell) <- subnodes) { ... }

[warn] /soft/lang/scala/configgy/src/main/scala/net/lag/configgy/Attributes.scala:128: match is not exhaustive!
[warn] missing combination     StringCell
[warn] missing combination StringListCell
[warn]     for ((key: String, cell) <- subnodes) {
[warn]                              ^

Well yeah, it's not exhaustive, but in that syntax the compiler discards
non-matching elements.  Normally one suppresses that warning with
@unchecked, but in addition to the fact that I shouldn't have to because
there's an implicit "filter out non-matching elements" in the desugar,
as near as I can tell there's nowhere you can put the annotation where
it will have an effect.

This is arguably a bug.

Writing this email just made me realize something amusing which I am
going to send to scala-user under separate cover.

--
Paul Phillips      | Those who can make you believe absurdities
Protagonist        | can make you commit atrocities.
Empiricist         |     -- Voltaire
slap pi uphill!    |----------* http://www.improving.org/paulp/ *----------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Option to treat warnings as errors?

Naftoli Gugenheim
By the way, why is the text after "missing combination" space-padded/right-aligned? At least in 2.7 when a type has a very long name the output is mangled.

On Mon, Apr 26, 2010 at 5:02 PM, Paul Phillips <[hidden email]> wrote:
On Mon, Apr 26, 2010 at 10:18:30AM +0100, Paul Butcher wrote:
> I'd be very interested to see an example of a warning that is
> generated for correct code and which can't easily be avoided.

From my branch of configgy:

 for ((key: String, cell) <- subnodes) { ... }

[warn] /soft/lang/scala/configgy/src/main/scala/net/lag/configgy/Attributes.scala:128: match is not exhaustive!
[warn] missing combination     StringCell
[warn] missing combination StringListCell
[warn]     for ((key: String, cell) <- subnodes) {
[warn]                              ^

Well yeah, it's not exhaustive, but in that syntax the compiler discards
non-matching elements.  Normally one suppresses that warning with
@unchecked, but in addition to the fact that I shouldn't have to because
there's an implicit "filter out non-matching elements" in the desugar,
as near as I can tell there's nowhere you can put the annotation where
it will have an effect.

This is arguably a bug.

Writing this email just made me realize something amusing which I am
going to send to scala-user under separate cover.

--
Paul Phillips      | Those who can make you believe absurdities
Protagonist        | can make you commit atrocities.
Empiricist         |     -- Voltaire
slap pi uphill!    |----------* http://www.improving.org/paulp/ *----------

Loading...