scoverage reports annotations must be constant when they are already final vals

[robconrad]

Scalac is able to compile annotations that are specified as final vals because those are acually constant (unlike a val or anything else). For example, this compiles:

object Foo {
  final val foo = 1L
}

@SerialVersionUID(value = Foo.foo)
class Bar

However, running scoverage:test on the above generates:

$ ./sbt scoverage:test 
[info] Loading project definition from ~/project
[info] Set current project to example 
[info] Compiling 2 Scala sources to ~/project/target/scala-2.11/scoverage-classes...
[scoverage]: Begin pre-instrumentation phase
[scoverage]: Pre-instrumentation complete
[error] ~/project/src/main/scala/com/coinposit/Foo.scala:7: annotation argument needs to be a constant; found: Foo.foo
[error] @SerialVersionUID(value = Foo.foo)
[error] 1 errors found
[error] (project/scoverage:compile) Compilation failed

Shouldn't scoverage be able to understand final vals as constant in annotations?

[sksamuel]

Yeah the issue is scoverage is wrapping the constant so that its no longer
constant. Thanks for bug report.

On 20 July 2014 06:07, robconrad notifications@github.com wrote:

Scalac is able to compile annotations that are specified as final vals
because those are acually constant (unlike a val or anything else). For
example, this compiles:

object Foo {
final val foo = 1L}
@serialversionuid(value = Foo.foo)class Bar

However, running scoverage:test on the above generates:

$ ./sbt scoverage:test
[info] Loading project definition from ~/project
[info] Set current project to example
[info] Compiling 2 Scala sources to ~/project/target/scala-2.11/scoverage-classes...
[scoverage]: Begin pre-instrumentation phase
[scoverage]: Pre-instrumentation complete
[error] ~/project/src/main/scala/com/coinposit/Foo.scala:7: annotation argument needs to be a constant; found: Foo.foo
[error] @serialversionuid(value = Foo.foo)
[error] 1 errors found
error Compilation failed

Shouldn't scoverage be able to understand final vals as constant in
annotations?

—
Reply to this email directly or view it on GitHub
#45.

[sksamuel]

Ok this requires some thought. What I do at the moment is any final vals
are un-finaled while testing, so we can see if they're used or not
(otherwise they get compiled away).

By doing this un-finaling, your annotation will no longer work. So the
question is can we support finals as well as allowing them to work in
annotations.

On 20 July 2014 09:42, Stephen Samuel (Sam) sam@sksamuel.com wrote:

Yeah the issue is scoverage is wrapping the constant so that its no longer
constant. Thanks for bug report.

On 20 July 2014 06:07, robconrad notifications@github.com wrote:

Scalac is able to compile annotations that are specified as final vals
because those are acually constant (unlike a val or anything else). For
example, this compiles:

object Foo {
final val foo = 1L}
@serialversionuid(value = Foo.foo)class Bar

However, running scoverage:test on the above generates:

$ ./sbt scoverage:test
[info] Loading project definition from ~/project
[info] Set current project to example
[info] Compiling 2 Scala sources to ~/project/target/scala-2.11/scoverage-classes...
[scoverage]: Begin pre-instrumentation phase
[scoverage]: Pre-instrumentation complete
[error] ~/project/src/main/scala/com/coinposit/Foo.scala:7: annotation argument needs to be a constant; found: Foo.foo
[error] @serialversionuid(value = Foo.foo)
[error] 1 errors found
error Compilation failed

Shouldn't scoverage be able to understand final vals as constant in
annotations?

—
Reply to this email directly or view it on GitHub
#45.

[robconrad]

Awesome, that's the fastest fix I've ever received!

[robconrad]

Is there a snapshot release I can pull to try it out or would I need to build the plugin myself?

[sksamuel]

You would need to build it yourself, the version number is already bumped
pending a release later.

On 20 July 2014 18:21, robconrad notifications@github.com wrote:

Is there a snapshot release I can pull to try it out or would I need to
build the plugin myself?

—
Reply to this email directly or view it on GitHub
#45 (comment)
.

[sksamuel]

0.99.7 is released

[robconrad]

Thanks! Unfortunately when I try to load sbt with the same settings I used with 0.99.5 (i.e. no configuration really, simply including it) I get this error:

Reference to undefined setting: 

  project/scoverage-itest:internalDependencyClasspath from project/scoverage-itest:internalDependencyClasspath

Is this something to do with my project? Any idea how I could start debugging it?

[robconrad]

Any hints?

[sksamuel]

Try the previous release, that should work.

On 4 August 2014 00:29, robconrad notifications@github.com wrote:

Any hints?

—
Reply to this email directly or view it on GitHub
#45 (comment)
.

[robconrad]

Er.. but the previous release doesn't have the final val fix right?

[sksamuel]

No but it'll work for the rest. Past week I've been working on this https://github.com/sksamuel/sbt-scapegoat but I'll get back onto scoverage this week and fix this properly.