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

Failing guard in pattern match causes incorrect behavior of later matches #4482

Closed
scabug opened this issue Apr 14, 2011 · 5 comments
Closed
Assignees
Labels
Milestone

Comments

@scabug
Copy link

scabug commented Apr 14, 2011

=== What steps will reproduce the problem? ===
Have two traits, one of which has an abstract method. Write a pattern-match expression, as below, where you first match trait A (with a pattern guard), then trait B, then trait A again. If you pass in an object that extends both A and B, and does NOT pass the boolean guard, the second match is skipped and the third match is selected. If you remove the first match (with the pattern guard) the behavior is as expected.

Basically, the presence of one failing match is causing the following match to fail, which it shouldn't.

Welcome to Scala version 2.9.0.RC1 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_24).
Type in expressions to have them evaluated.
Type :help for more information.

scala> {
     |   trait Foo  {
     |     def i: Int
     |   }
     |   trait Bar
     | 
     |   case class Spam(i: Int) extends Foo with Bar
     | 
     |   def matchParent(p:Any) = p match {
     |     case f:Foo if f.i == 1 => 1
     |     case _:Bar => 2
     |     case _:Foo => 3
     |   }
     | 
     |   matchParent(Spam(3))
     | }
res0: Int = 3

scala> {
     |   trait Foo  {
     |     def i: Int
     |   }
     |   trait Bar
     | 
     |   case class Spam(i: Int) extends Foo with Bar
     | 
     |   def matchParent(p:Any) = p match {
     |     case _:Bar => 2
     |     case _:Foo => 3
     |   }
     | 
     |   matchParent(Spam(3))
     | }
res1: Int = 2

=== What is the expected behavior? ===
Both of the above expressions should resolve to 2.

=== What do you see instead? ===
The first expression resolves to 3, skipping the second match.

=== What versions of the following are you using? ===

  • Scala: 2.9.0.RC1 (also occurs in 2.8.1)
  • Java: 1.6.0_24
  • Operating system: OS X 10.6.7
@scabug
Copy link
Author

scabug commented Apr 14, 2011

Imported From: https://issues.scala-lang.org/browse/SI-4482?orig=1
Reporter: Stephen Judkins (stephenjudkins)
Attachments:

  • bug4482.patch (created on Apr 14, 2011 8:15:19 PM UTC, 876 bytes)

@scabug
Copy link
Author

scabug commented Apr 14, 2011

Stephen Judkins (stephenjudkins) said:
Patch adding failing test

@scabug
Copy link
Author

scabug commented Apr 14, 2011

Stephen Judkins (stephenjudkins) said:
The problem seems to be introduced in the "explicitouter" compiler stage:

    def matchParent(p: Any): Int = {
      <synthetic> def gd2(x$$1: com.wtf.Main.Foo): Boolean = x$$1.i().==(1);
      {
        <synthetic> val temp5: Any = p;
        if (temp5.isInstanceOf[com.wtf.Main.Foo]())
          {
            if (gd2(temp5.asInstanceOf[com.wtf.Main.Foo]()))
              {
                1
              }
            else
              {
                3
              }
          }
        else
          if (temp5.isInstanceOf[com.wtf.Main.Bar]())
            {
              2
            }
          else
            throw new MatchError(temp5)
      }
    };

It appears the generated code branches on whether it's an instance of "Foo" first, only branching based on the guard after it's determined it will match one of the "Foo" cases.

@scabug
Copy link
Author

scabug commented Apr 18, 2011

@magarciaEPFL said:
Yes, matchParent(Spam(3)) returns 3 when defined as

  def matchParent(p:Any) = p match {
    case f:Foo if f.i == 1 => 1
    case _:Bar => 2
    case _:Foo => 3
  }

However when compiled with -Ypmat-naive it returns 2.

The other option that comes to mind (-Yno-squeeze) makes compiled code return 3.

@scabug
Copy link
Author

scabug commented May 11, 2012

@soc said:
Fixed in scala/scala@4c04213

@scabug scabug closed this as completed May 11, 2012
@scabug scabug added the patmat label Apr 7, 2017
@scabug scabug added this to the 2.10.0 milestone Apr 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants