Scala-dev: Enable fatal warnings in remaining subprojects of scala/scala

[SethTisue]

now that we have @nowarn and -Wconf, enabling fatal warnings in the scala/scala build is now feasible and the major subprojects (compiler, reflect, library, ...) are already done.

over at #600 @NthPortal offered this list of subprojects still needing this switch flipped:

• [x] testkit (scala/scala#9348)
• [x] partest (scala/scala#9348)
• [x] tastytest (scala/scala#9348)
• [x] specLib (scala/scala#9348)
• [ ] bench (maybe)
• [x] junit (scala/scala#9348)
• [ ] tasty
• [ ] scalacheck
• [ ] osgiTestFelix (?)
• [ ] osgiTestEclipse (?)
• [ ] partestJavaAgent
• [ ] enable warnings (and thus errors) in doc stage when fatal warnings are enabled

volunteers to tackle particular checkboxes here...?

[som-snytt]

I may need something brainless to do while they count votes here, so I'll try testkit, which ought to be warnless, and after that I'll take on partest, hoping that all I need to do is:

package scala.tools
@nowarn
package object partest

[NthPortal]

I do not envy whoever takes on junit (edit: oh look, it was me)

[NthPortal]

oops, too late, I already did testkit and partest 😬
I missed your message and I was just doing them in order

[som-snytt]

In order would be partest then testkit.

[NthPortal]

I changed the order, because partest depends on testkit >.>

[dwijnand]

I'm thinking we can/should close this off, as the ROI isn't there IMO. WDYT? That's not to say getting those projects to be fatal on their warnings won't be merged.

[SethTisue]

yeah, if someone wants to tackle the remaining checkboxes it would certainly be welcome, but I don't think we need to keep an open ticket around.

[som-snytt]

I see warnings on scalacheck test but not javaPartestAgent, maybe the list of projects were not yet checked out for warnings.

Downside of strict warnings:

[error] .../src/compiler/scala/tools/nsc/plugins/Plugin.scala:170:9: method trace in class quickie stack dump is deprecated (since forever): For debug only
[error]         trace"dup ${pd.classname}"

where the deprecation is intentional but not intended to stop you from using it for debug. So the intuition is that some settings are appropriate for a later or final phase of workflow. Or a "verify" task that adds extra checks to "test".

Closing per previous comment.

[NthPortal]

let's not forget warnings in the doc stage though

[som-snytt]

How could we forget? I mean, if only we could forget.