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

spurious unreachability with guarded default, and unpositioned warning

    Details

      Description

      In the following, both f1 and f2 receive incorrect unreachable warnings. In the second variation, the warning is completely unpositioned - it literally just emits "warning: unreachable code". Since the file I was compiling at the time had about a thousand pattern matches in it, I was reminded of the value of accurate positions.

      class A {
        def f1(x: Int) = x match {
          case _ if false => x
          case 5          => x
        }
        // patmat.scala:4: warning: unreachable code
        //     case 5          => x
        //                        ^
        def f2(x: Int) = x match {
          case _ if false => x
          case 5 if true  => x
        }
        // warning: unreachable code
      }
      

        Issue Links

          Activity

          Hide
          Adriaan Moors added a comment -

          aside from the positions debacle, the first case of both matches should be considered unreachable, right?

          Show
          Adriaan Moors added a comment - aside from the positions debacle, the first case of both matches should be considered unreachable, right?
          Hide
          Paul Phillips added a comment -

          Oh I see, you're letting literal false have "false.type" and not boolean. Technically you're right. Traditionally we don't utilize that information, because a guard of "if true" or "if false" almost certainly represents some kind of debugging.

          It is like, if every time you saw

          if (false && condition)

          { ... }

          You said "Warning! Block of code will never execute!" Well yeah, that's why I put "if (false)" in there, you don't need to hassle me about it scalac.

          I could go either way on this, but in the absence of someone identifying a plausible case where this is helpful, I'd say the type of the guard should be widened.

          Show
          Paul Phillips added a comment - Oh I see, you're letting literal false have "false.type" and not boolean. Technically you're right. Traditionally we don't utilize that information, because a guard of "if true" or "if false" almost certainly represents some kind of debugging. It is like, if every time you saw if (false && condition) { ... } You said "Warning! Block of code will never execute!" Well yeah, that's why I put "if (false)" in there, you don't need to hassle me about it scalac. I could go either way on this, but in the absence of someone identifying a plausible case where this is helpful, I'd say the type of the guard should be widened.
          Hide
          Paul Phillips added a comment -

          And maybe this was included in "positions debacle" but the one warning which is positioned is positioned on the wrong line entirely (otherwise I might have noticed what it was doing.)

          Show
          Paul Phillips added a comment - And maybe this was included in "positions debacle" but the one warning which is positioned is positioned on the wrong line entirely (otherwise I might have noticed what it was doing.)
          Hide
          Adriaan Moors added a comment -

          yeah, that was happening because i was checking unreachability after pushing guards into the bodies of switch cases, so that then it looked like there was an unguarded default followed by another case

          Show
          Adriaan Moors added a comment - yeah, that was happening because i was checking unreachability after pushing guards into the bodies of switch cases, so that then it looked like there was an unguarded default followed by another case
          Hide
          Adriaan Moors added a comment -

          with regards to widening types of guards – I'm not sure
          constant folding is admittedly limited, but what if someone accidentally wrote something that folds to false?

          Show
          Adriaan Moors added a comment - with regards to widening types of guards – I'm not sure constant folding is admittedly limited, but what if someone accidentally wrote something that folds to false?
          Hide
          Adriaan Moors added a comment -

          just to be sure

          def test1(x: Int) = x match {
            case c if c < 0 => 0
            case 1          => 1
            case _          => 2
          }
          
          Show
          Adriaan Moors added a comment - just to be sure def test1(x: Int) = x match { case c if c < 0 => 0 case 1 => 1 case _ => 2 }
          Show
          Adriaan Moors added a comment - https://github.com/scala/scala/pull/866

            People

            • Assignee:
              Adriaan Moors
              Reporter:
              Paul Phillips
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development