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

regression: return is treated as a break in a breakable code

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: Scala 2.10.0-M2
    • Fix Version/s: Scala 2.10.0
    • Component/s: None
    • Labels:

      Description

      Reported by Richard Emberson on scala-user, minimized:

      object L extends Enumeration {
        val One, Two, Three = Value
      }
      
      class Foo {
        def foo(xs: List[L.Value]) {
          import scala.util.control.Breaks.{break, breakable}
          println("START for " + xs)
          breakable {
            for (x <- xs) {
              x match {
                case L.One => println("ONE"); return
                case L.Two => println("TWO")
                case L.Three => println("THREE"); break
              }
            }
          }
          println("FINISH")
        }
      }
      
      object Test {
        def main(args: Array[String]) {
          val f = new Foo()
          val l = List(L.Two, L.Two, L.One, L.Three)
          f.foo(l)
        }
      }
      

      in 2.10.0-M2:

      START for List(Two, Two, One, Three)
      TWO
      TWO
      ONE
      

      in latest nightly (a532ba):
      compiles with warning:

      warning: non variable type-argument Unit in type pattern scala.runtime.NonLocalReturnControl[Unit] is unchecked since it is eliminated by erasure
      

      output:

      START for List(Two, Two, One, Three)
      TWO
      TWO
      ONE
      FINISH
      

        Activity

        Hide
        Hubert Plociniczak added a comment -

        It seems to be caused by this catch block generated during uncurry for NonLocalReturnControl.
        The old code:

        
        } catch {
          case (ex @ (_: scala.runtime.NonLocalReturnControl[Foo.this._])) => if (ex.key().eq(nonLocalReturnKey1))
            ex.value().asInstanceOf[Unit]()
          else
            throw ex
        }
        

        vs the new one:

        } catch {
          case (ex @ (_: scala.runtime.NonLocalReturnControl[Unit])) => if (ex.key().eq(nonLocalReturnKey1))
            ex.value()
          else
            throw ex
        }
        
        Show
        Hubert Plociniczak added a comment - It seems to be caused by this catch block generated during uncurry for NonLocalReturnControl. The old code: } catch { case (ex @ (_: scala.runtime.NonLocalReturnControl[Foo.this._])) => if (ex.key().eq(nonLocalReturnKey1)) ex.value().asInstanceOf[Unit]() else throw ex } vs the new one: } catch { case (ex @ (_: scala.runtime.NonLocalReturnControl[Unit])) => if (ex.key().eq(nonLocalReturnKey1)) ex.value() else throw ex }
        Hide
        Paul Phillips added a comment -

        I already tracked this down and reverted the commit which caused it, but that broke the build and the revert was unreverted.

        See 5af2bf54d2 and 3db29dde05 .

        The commit which caused it is 19a48510c .

        The "non-variable type argument" spurious warning is unrelated.

        Show
        Paul Phillips added a comment - I already tracked this down and reverted the commit which caused it, but that broke the build and the revert was unreverted. See 5af2bf54d2 and 3db29dde05 . The commit which caused it is 19a48510c . The "non-variable type argument" spurious warning is unrelated.
        Hide
        Hubert Plociniczak added a comment -

        Ah, the infamous revert of the revert. Thanks for the info.

        Show
        Hubert Plociniczak added a comment - Ah, the infamous revert of the revert. Thanks for the info.
        Hide
        Richard Emberson added a comment -

        Wow, I guess I am really surprised that 2.10.0-M3 would be
        released without first fixing this show-stopper.
        I'd like to incorporate some of the new features being
        highlighted in the 2.10.0-M3 but can not because a couple
        of my libraries have failed to compile for over a month
        due to the "fix" 19a48510c.
        I kept waiting for this to be addressed so that I could
        go back to using the git-head rather than 2.10.0-M2.

        Show
        Richard Emberson added a comment - Wow, I guess I am really surprised that 2.10.0-M3 would be released without first fixing this show-stopper. I'd like to incorporate some of the new features being highlighted in the 2.10.0-M3 but can not because a couple of my libraries have failed to compile for over a month due to the "fix" 19a48510c. I kept waiting for this to be addressed so that I could go back to using the git-head rather than 2.10.0-M2.
        Hide
        Seth Tisue added a comment -

        I don't really know what a "milestone" is or should be, but I would agree that nothing with this bug should be called a release candidate.

        Show
        Seth Tisue added a comment - I don't really know what a "milestone" is or should be, but I would agree that nothing with this bug should be called a release candidate.
        Hide
        Paul Phillips added a comment -

        In principle milestones are time-based and indifferent to the presence or absence of any particular fix; the only milestone-specific effort is to endeavor to make sure it works with sbt, the ide, etc.

        Show
        Paul Phillips added a comment - In principle milestones are time-based and indifferent to the presence or absence of any particular fix; the only milestone-specific effort is to endeavor to make sure it works with sbt, the ide, etc.
        Hide
        Paul Phillips added a comment -

        aad6deae72

        Show
        Paul Phillips added a comment - aad6deae72

          People

          • Assignee:
            Paul Phillips
            Reporter:
            Hubert Plociniczak
          • Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development