Skip to content

Commit

Permalink
Merge pull request #679 from hrhino/patch-1
Browse files Browse the repository at this point in the history
remove reference to fixed SI-8700
  • Loading branch information
eed3si9n authored May 29, 2018
2 parents 1bebf3f + 0f84188 commit 67d088a
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 67d088a

Please sign in to comment.