Add FinalVal wart

[tim-zh]

No description provided.

[tim-zh]

any update on this?

should i add the following example to readme?

$ echo "object a { final val v = 1 }" > a.scala
$ echo "object b extends App { println(a.v) }" > b.scala
$ sbt ~run
1
$ echo "object a { final val v = 2 }" > a.scala
1

[ClaireNeveu]

What is the proposed workaround for this situation?

[ClaireNeveu]

Also, is there a bug filed against scala that we can link to?

[dwijnand]

It's in the spec, it's expected behaviour.

[tim-zh]

workaround is to use non-final vals

it's not a Scala bug, but it's still quite unsafe

[ClaireNeveu]

@dwijnand Inlining is certainly in the spec but the incremental compiler not recompiling dependent files due to inlining is not (to my knowledge).

@tim-zh My concern there is that making a val non-final changes the semantics and people use final for a reason. I think we could say in the error message to use final def instead which does not seem to break incremental compiliation but preserves the desired semantics.

[dwijnand]

Yeah, I agree with you there. We should open a ticket against Zinc to fix it.

[dwijnand]

Btw it's constant-folding, not inlining.

And making it a def or adding a type ascription to the val are other alternatives.

val v: Int = 1
def v: Int = 1
final val v: Int = 1

[tim-zh]

@dwijnand Indeed, thanks. It's a bit trickier than i thought, and it means the pr can't be merged :(, since we can't prevent false positives right now.

[ClaireNeveu]

@tim-zh I think the only false-positive you're missing is final val v: Int = 1, which doesn't get folded. You can take the approach from ExplicitImplicitTypes to check for the annotation. Unlike with defs, the annotation should always be on the same line for vals. The only false positives we should see there are final vals generated by macro expansion which we'll hopefully have an answer for soon.

[ClaireNeveu]

This looks set to merge to me and it'll go out in 1.1.0. The one additional thing I'd like to see is a ticket for the bug against Zinc so we can link to it in the README. Since this wart is related to an actual bug I want to know when it stops being relevant (due to a bugfix).

[tim-zh]

@ChrisNeveu sbt/sbt/issues/1543 ?

[ClaireNeveu]

Thanks! I'll add a link to that in the README.

[adriaanm]

by the way, the incremental compiler now tracks these kind of constant vals