More thorough treatment of @strictfp. #7356
Conversation
|
(targets 2.13.x branch, but you put it on the 2.12.8 milestone?) |
|
🙀 I should have just let scabot catch my mistake. Thanks! (Targets 2.12.8 because I'm hopeful. It could also be 2.13, no worries) |
(Just getting my toes wet again.) The JVM accepts `ACC_STRICT` as a modifier flag on non-abstract methods only. Java itself accepts `strictfp` on both methods (in which case it applies to the method) and classes (in which case it applies to all methods within the class, as well as nested and inner classes thereof.) Scala has somewhat more ways of nesting methods and classes than Java, so I've extrapolated the rule to be: methods nested inside of a class/module/method definition marked `@strictfp` are strict. I also fixed the interaction with value classes: when a method body on a value class was moved to the companion, its `@strictfp` attribute wasn't moved along with it. The test case covers nested/inner/local classes and methods, as well as extension methods. I'm leaving specialization to the existing specialization+strictfp tests. Fixes scala/bug#7954.
|
@hrhino test failures on Windows at e.g. https://scala-ci.typesafe.com/view/scala-2.12.x/job/scala-2.12.x-integrate-windows/1156/ , this PR seems like the likely culprit |
|
it's also failing on Travis. Haven't had a chance yet to see what exactly, but it's in test/files/jvm/strictfp: Running update-check gives: --- i/test/files/jvm/strictfp.check
+++ w/test/files/jvm/strictfp.check
@@ -23,8 +23,8 @@ H$I$.bar$10: true
I.foo: false
I$.foo: true
I$.foo$extension: false
-I$.bar$11: false
-I$.bar$12: true
+I$.bar$11: true
+I$.bar$12: false
J.foo: true
J$M$1.foo: true
J$M$1.bar$13: truedoes that look right? |
|
Could perhaps be an interaction with the compiler determinism PR that re-ordered symbols? |
|
yikes. evidently I need to start borrowing my girlfriend's windows laptop more often... The determinism backport PR got merged after this one (dunno why I thought it had been merged before this; sorry). I'll send in a checkfile fix. |
Also test that the Java parser doesn't force entry of new symbols when it parses modifiers that it translates into symbol annotations. Regressed in scala#7356
Also test that the Java parser doesn't force entry of new symbols when it parses modifiers that it translates into symbol annotations. Regressed in scala#7356
Also test that the Java parser doesn't force entry of new symbols when it parses modifiers that it translates into symbol annotations. Regressed in scala#7356
The JVM accepts
ACC_STRICTas a modifier flag on non-abstract methods only. Java itself acceptsstrictfpon both methods (in which case it applies to the method) and classes (in which case it applies to all methods within the class, as well as nested and inner classes thereof.) Scala has somewhat more ways of nesting methods and classes than Java, so I've extrapolated the rule to be: methods nested inside of a class/module/method definition marked@strictfpare strict.I also fixed the interaction with value classes: when a method body on a value class was moved to the companion, its
@strictfpattribute wasn't moved along with it.The test case covers nested/inner/local classes and methods, as well as extension methods. I'm leaving specialization to the existing specialization+strictfp tests.
Fixes scala/bug#7954.