-Xexperimental exhaustive check for virtpatmat

[Som Snytt]

"Is the -Xexperimental exhaustive check for virtpatmat known to be experimentally non-deterministic?"

"I dunno, let me google.  Yes, here it is."

https://issues.scala-lang.org/browse/SI-7020

"OK, that was easy.  That google is pretty nifty.  I found this because I added stderr output to partest logs a few weeks ago, and these were the only tests that couldn't pass, no matter how many times I ran --update-check.  I'm kind of glad the kitteh is not sitting in a loop doing --update-check until the tests pass.  Which sounded like a good idea at the time."

"How about implementing the line filter to remove it from the log file?  There's a ticket for that."

https://issues.scala-lang.org/browse/SI-7198

"OK, I'll do that.  The stderr > log change didn't make it into the last Par-Test PR, but there is already a ticket for that, too."

https://issues.scala-lang.org/browse/SI-7003

"Sounds good, but don't do anything that makes it noisy again.  And why do you call it Par-Test with a hyphen?"

"It's like Spider-Man.  'Catches bugs just like flies.'  And par like in golf."

"Really?  I thought it was par like parallel."

"No, then you'd have to pronounce it more like Pear-Test.  I'm pretty sure it's par like in golf."

apm@mara:~/projects/scala-pick/test$ ../build/pack/bin/scalac -Xexperimental -d /tmp files/run/virtpatmat_opt_sharing.scala
files/run/virtpatmat_opt_sharing.scala:4: warning: match may not be exhaustive.
It would fail on the following inputs: List((x: Int forSome x not in 1), 3, _), List(_, (x: Int forSome x not in 3), _), List(_, (x: Int forSome x not in 3), _, (x: Int forSome x not in (5, 6))), List(_, (x: Int forSome x not in 3), _, (x: Int forSome x not in (6, 7))), List(_, (x: Int forSome x not in 3), _, (x: Int forSome x not in 6)), List(_, (x: Int forSome x not in 3), _, 6), List(_, (x: Int forSome x not in 3), _, ??), List(_, _, (x: Int forSome x not in 4))
    List(1, 3, 4, 7) match {
        ^
one warning found
apm@mara:~/projects/scala-pick/test$ ../build/pack/bin/scalac -Xexperimental -d /tmp files/run/virtpatmat_opt_sharing.scala
files/run/virtpatmat_opt_sharing.scala:4: warning: match may not be exhaustive.
It would fail on the following inputs: List((x: Int forSome x not in 1), 3, 4, (x: Int forSome x not in (5, 6))), List(_, (x: Int forSome x not in 3), _, _), List(_, 3, (x: Int forSome x not in 4), (x: Int forSome x not in (5, 6, 7))), List(_, 3, 4, (x: Int forSome x not in (5, 6, 7)))
    List(1, 3, 4, 7) match {
        ^
one warning found
apm@mara:~/projects/scala-pick/test$ ../build/pack/bin/scalac -Xexperimental -d /tmp files/run/virtpatmat_opt_sharing.scala
files/run/virtpatmat_opt_sharing.scala:4: warning: match may not be exhaustive.
It would fail on the following inputs: List(1, (x: Int forSome x not in 3), 4, 5), List(_, (x: Int forSome x not in 3), 4, 7), List(_, _, (x: Int forSome x not in 4)), List(_, _, (x: Int forSome x not in 4), _), List(_, _, 4, (x: Int forSome x not in (5, 6, 7)))
    List(1, 3, 4, 7) match {
        ^

[Adriaan Moors]

That feature has since graduated and has gotten pretty snobby (and vindictive!) about its former experimental label.

Proposed solution: git rm -f files/run/virtpatmat_opt_sharing.flags

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

See you at Scala Days (June 10–12, NYC)!

[Som Snytt]

OK, thanks, I'll do that.

I'm not sure it's a solution per se for the test.  I'll implement the line filter, since it's needed elsewhere anyway.

Maybe we could change the warning to: "It would fail on some random permutation of the following inputs."

apm@mara:~/projects/snytt/test$ skalac -d /tmp files/run/virtpatmat_opt_sharing.scala

files/run/virtpatmat_opt_sharing.scala:4: warning: match may not be exhaustive.

It would fail on the following inputs: List((x: Int forSome x not in 1), _, _, (x: Int forSome x not in (5, 7))), List(1, (x: Int forSome x not in 3), _, (x: Int forSome x not in (5, 7))), List(_, (x: Int forSome x not in 3), 4, 7), List(_, (x: Int forSome x not in 3), _, 5), List(_, _, _), List(_, _, _, (x: Int forSome x not in (5, 6, 7)))

    List(1, 3, 4, 7) match {
        ^
one warning found

apm@mara:~/projects/snytt/test$ skalac -d /tmp files/run/virtpatmat_opt_sharing.scala

files/run/virtpatmat_opt_sharing.scala:4: warning: match may not be exhaustive.

It would fail on the following inputs: List(_, (x: Int forSome x not in 3), 4, (x: Int forSome x not in (5, 6))), List(_, (x: Int forSome x not in 3), _, 5), List(_, (x: Int forSome x not in 3), _, 6), List(_, _, (x: Int forSome x not in 4), _), List(_, _, _)

    List(1, 3, 4, 7) match {
        ^
one warning found

apm@mara:~/projects/snytt/test$ whence skalac
skalac is aliased to `JAVACMD='/usr/lib/jvm/java-7-openjdk-amd64/bin/java' /home/apm/projects/snytt/build/pack/bin/scalac -Dline.separator=$'\n''
apm@mara:~/projects/snytt/test$

[Adriaan Moors]

IT's not supposed to be non-deterministic. To illustrate my intent: I sort the counter-examples. However, sorting does a changing list no good when it's consistency you're after. I assumed it'd become deterministic without -Xexperimental, so now it's definitely a (minor) bug.

[Som Snytt]

OK, thanks, I'll take a closer look, without actually falling into the volcano.

For the nonce, it will be filterable:

apm@mara:~/projects/snytt/test$ ./partest --update-check ./files/run/virtpatmat_opt_sharing.scala  ./files/run/virtpatmat_alts.scala ./files/run/virtpatmat_nested_lists.scala
Selected 3 tests drawn from specified tests

# starting 3 tests in run
++ 1 - run/virtpatmat_nested_lists.scala         [updated check file]
ok 2 - run/virtpatmat_opt_sharing.scala       
++ 3 - run/virtpatmat_alts.scala                 [updated check file]

3/3 passed (elapsed time: 00:00:07)
Test Run PASSED

[Som Snytt]

https://issues.scala-lang.org/browse/SI-7003

Under the aegis of this issue, with the rubric, "Don't lose test output because you never know if it matters to someone," there's a PR to preserve stderr, which includes compiler warnings.

The upside is that it keeps the test code free of dust; the downside is that the test writer has to cope with warnings.

It's no big deal to either eliminate warnings by fixing the test or to enshrine them in the check file; if the warning changes its shape, such as with the exhaustiveness roulette warning or inliner warnings that pop up under -optimise, then the current solution is to filter those lines with a header comment:

/*
 * filter: inliner warning(s); re-run with -Yinline-warnings for details
 */

(It's confusing/annoying for a test to fail because of -optimise (this we knew); and it would be nice if the transcript could collate commands and outputs, or even better, if the transcript diff could do that. The "re-run with -XXX for details" messages don't include the source file, for instance.)

run/t5568.scala shows the following warnings.  I haven't looked at why the REPL is so upset about the dot.  I'm not running it with -Ysave-the-dots, which automatically sends a paypal donation to a children's orphanage in Uganda for every extraneous dot.

apm@mara:~/projects/snytt$ skala -deprecation -feature
Welcome to Scala version 2.11.0-20130524-174214-08a368770c (OpenJDK 64-Bit Server VM, Java 1.7.0_21).
Type in expressions to have them evaluated.
Type :help for more information.

scala> 5.##
<console>:1: warning: This lexical syntax is deprecated.  From scala 2.11, a dot will only be considered part of a number if it is immediately followed by a digit.
       5.##
       ^
<console>:2: warning: This lexical syntax is deprecated.  From scala 2.11, a dot will only be considered part of a number if it is immediately followed by a digit.
              5.##
              ^
<console>:8: warning: This lexical syntax is deprecated.  From scala 2.11, a dot will only be considered part of a number if it is immediately followed by a digit.
              5.##
              ^
<console>:8: warning: postfix operator ## should be enabled
by making the implicit value scala.language.postfixOps visible.
This can be achieved by adding the import clause 'import scala.language.postfixOps'
or by setting the compiler option -language:postfixOps.
See the Scala docs for value scala.language.postfixOps for a discussion
why the feature should be explicitly enabled.
              5.##
                ^
res0: Int = 5

Bonus example of laboriously re-running a test for details; it would be nice if I never had to do this:

apm@mara:~/projects/snytt/test$ SCALAC_OPTS="-optimise -feature" ./partest --show-diff files/run/t4729
Selected 1 tests drawn from specified tests

# starting 1 test in run
!! 1 - run/t4729                                 [output differs]
% diff files/run/t4729-run.log files/run/t4729.check
@@ -1,11 +1,3 @@
-S_2.scala:16: warning: reflective access of structural type member method method should be enabled
-by making the implicit value scala.language.reflectiveCalls visible.
-This can be achieved by adding the import clause 'import scala.language.reflectiveCalls'
-or by setting the compiler option -language:reflectiveCalls.
-See the Scala docs for value scala.language.reflectiveCalls for a discussion
-why the feature should be explicitly enabled.
-    varArgs.method("1", "2")
-            ^
 WrappedArray(1, 2)