Skip to content

Commit

Permalink
remove reference to fixed SI-8700
Browse files Browse the repository at this point in the history
as requested/suggested on Gitter.

Also fiddle with the text to imply the fix in scala/scala#5487.
  • Loading branch information
hrhino authored May 24, 2018
1 parent 30b6694 commit 0f84188
Showing 1 changed file with 2 additions and 4 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -64,17 +64,15 @@ compile will always provide full checking, however.

The Scala compiler does not identify compile-time constant variables
(Java specification [4.12.4](http://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.12.4))
as such when parsing a Java file from source.
in Java source code if their definition is not a literal.
This issue has several symptoms, described in the Scala ticket [SI-5333](https://github.com/scala/bug/issues/5333):

1. The selection of a constant variable is rejected when used as an argument
1. The selection of a (non-literal) constant variable is rejected when used as an argument
to a Java annotation (a compile-time constant expression is required).
2. The selection of a constant variable is not replaced by its value, but compiled
as an actual field load (the
[Scala specification 4.1](http://www.scala-lang.org/files/archive/spec/2.11/04-basic-declarations-and-definitions.html#value-declarations-and-definitions)
defines that constant expressions should be replaced by their values).
3. Exhaustiveness checking does not work when pattern matching on the values of a
Java enumeration ([SI-8700](https://github.com/scala/bug/issues/8700)).

Since Scala 2.11.4, a similar issue arises when using a Java-defined annotation in
a Scala class. The Scala compiler does not recognize `@Retention` annotations when
Expand Down

0 comments on commit 0f84188

Please sign in to comment.