Scala Programming Language
  1. Scala Programming Language
  2. SI-7409

partest: compiler crashes, then reports test passed

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: Scala 2.11.0-M3
    • Component/s: Partest
    • Labels:
      None

      Description

      % test/partest --failed --update-check
      Selected 9 tests drawn from previously failed tests
      
      # starting 5 tests in neg
      exception when typing $this.i().hashCode()/class scala.reflect.internal.Trees$Apply
      class Funky is abstract; cannot be instantiated in file /scratch/trunk4/test/files/neg/t6283.scala
      scala.reflect.internal.Types$TypeError: class Funky is abstract; cannot be instantiated
      	at scala.tools.nsc.typechecker.Contexts$Context.issueCommon(Contexts.scala:420)
      	at scala.tools.nsc.typechecker.Contexts$Context.issue(Contexts.scala:424)
      	at scala.tools.nsc.typechecker.Infer$Inferencer.issue(Infer.scala:307)
      	at scala.tools.nsc.typechecker.Typers$Typer$$anonfun$normalTypedApply$1$1.apply(Typers.scala:4494)
      	at scala.tools.nsc.typechecker.Typers$Typer$$anonfun$normalTypedApply$1$1.apply(Typers.scala:4494)
      	at scala.tools.nsc.typechecker.Typers$Typer.onError$3(Typers.scala:4465)
      	at scala.tools.nsc.typechecker.Typers$Typer.normalTypedApply$1(Typers.scala:4494)
      	at scala.tools.nsc.typechecker.Typers$Typer.typedApply$1(Typers.scala:4521)
      	at scala.tools.nsc.typechecker.Typers$Typer.typed1(Typers.scala:5205)
      ...
      unhandled exception while transforming t6283.scala
      ok   1 - neg/t6283.scala                         
      ...
      
      9/9 passed (elapsed time: 00:00:16)
      Test Run PASSED
      

        Activity

        Hide
        Paul Phillips added a comment -

        It seems it will happily update the checkfile with the crash dump. The key is that in neg tests it needs to distinguish between crashes and other non-zero exit codes.

        Show
        Paul Phillips added a comment - It seems it will happily update the checkfile with the crash dump. The key is that in neg tests it needs to distinguish between crashes and other non-zero exit codes.
        Hide
        A. P. Marki added a comment -

        I bet you don't mind if I look at it; I just looked at scalacheck fails not failing.

        My PR will arrive in what will seem like dog years to you, or years to a dog traveling near the speed of light.

        Show
        A. P. Marki added a comment - I bet you don't mind if I look at it; I just looked at scalacheck fails not failing. My PR will arrive in what will seem like dog years to you, or years to a dog traveling near the speed of light.
        Hide
        Jason Zaugg added a comment -

        A drive by feature request: add a third status, 'updated', to go with 'ok', and 'fail'.

        Show
        Jason Zaugg added a comment - A drive by feature request: add a third status, 'updated', to go with 'ok', and 'fail'.
        Hide
        A. P. Marki added a comment -

        And skipped! And crashed! And burned!

        My other branch adds, let's see, timeout! and canceled! I guess error means crashed?

        "Drive-by" or is it "drive-through"? Like In'n'Out!

        Show
        A. P. Marki added a comment - And skipped! And crashed! And burned! My other branch adds, let's see, timeout! and canceled! I guess error means crashed? "Drive-by" or is it "drive-through"? Like In'n'Out!
        Hide
        A. P. Marki added a comment -

        One more: when you specify flags, you should be able to specify conditions under which a test must be skipped because it must fail, e.g., not enough memory for a huge BitSet. There's no reason to run a test that can't possibly succeed under the test conditions. I'm open to suggestions for a naming convention for "set up to fail" status.

        And why is there updated but no downdated? Or is that when there is no second date?

        Show
        A. P. Marki added a comment - One more: when you specify flags, you should be able to specify conditions under which a test must be skipped because it must fail, e.g., not enough memory for a huge BitSet. There's no reason to run a test that can't possibly succeed under the test conditions. I'm open to suggestions for a naming convention for "set up to fail" status. And why is there updated but no downdated? Or is that when there is no second date?
        Hide
        A. P. Marki added a comment -

        https://github.com/scala/scala/pull/2446

        includes "updated" status. Does not actually distinguish between crashing and burning.

        Show
        A. P. Marki added a comment - https://github.com/scala/scala/pull/2446 includes "updated" status. Does not actually distinguish between crashing and burning.
        Show
        A. P. Marki added a comment - https://github.com/scala/scala/pull/2476

          People

          • Assignee:
            A. P. Marki
            Reporter:
            Paul Phillips
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development