Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spurious unreachability with guarded default, and unpositioned warning #6048

Closed
scabug opened this issue Jul 9, 2012 · 8 comments
Closed
Assignees
Milestone

Comments

@scabug
Copy link

scabug commented Jul 9, 2012

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
}
@scabug
Copy link
Author

scabug commented Jul 9, 2012

Imported From: https://issues.scala-lang.org/browse/SI-6048?orig=1
Reporter: @paulp

@scabug
Copy link
Author

scabug commented Jul 10, 2012

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

@scabug
Copy link
Author

scabug commented Jul 10, 2012

@paulp said:
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.

@scabug
Copy link
Author

scabug commented Jul 10, 2012

@paulp said:
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.)

@scabug
Copy link
Author

scabug commented Jul 10, 2012

@adriaanm said:
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

@scabug
Copy link
Author

scabug commented Jul 10, 2012

@adriaanm said:
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?

@scabug
Copy link
Author

scabug commented Jul 10, 2012

@adriaanm said:
just to be sure

def test1(x: Int) = x match {
  case c if c < 0 => 0
  case 1          => 1
  case _          => 2
}

@scabug
Copy link
Author

scabug commented Jul 11, 2012

@adriaanm said:
scala/scala#866

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants