Merge pull request #3515 from retronym/topic/stable-ident-ambiguous

A test case for a name binding progression

2 files changed, 31 insertions, 0 deletions

diff --git a/test/files/neg/name-lookup-stable.check b/test/files/neg/name-lookup-stable.check
new file mode 100644
index 0000000000..751df9505e
--- /dev/null
+++ b/test/files/neg/name-lookup-stable.check
@@ -0,0 +1,11 @@
+name-lookup-stable.scala:15: error: reference to PrimaryKey is ambiguous;
+it is both defined in class A and imported subsequently by
+import ColumnOption._
+    (null: Any) match { case PrimaryKey => }
+                             ^
+name-lookup-stable.scala:17: error: reference to PrimaryKey is ambiguous;
+it is both defined in class A and imported subsequently by
+import ColumnOption._
+    PrimaryKey // was already ambigious in 2.10.3
+    ^
+two errors found
diff --git a/test/files/neg/name-lookup-stable.scala b/test/files/neg/name-lookup-stable.scala
new file mode 100644
index 0000000000..0d862f06e1
--- /dev/null
+++ b/test/files/neg/name-lookup-stable.scala
@@ -0,0 +1,20 @@
+// This used to compile under 2.10.3 but the ambiguity is now noticed
+// in 2.11.x (after a70c8219). I think the new behaviour is correct;
+// we shouldn't discard names based on "expected stability" before
+// evaluating ambiguity.
+object ColumnOption {
+  object PrimaryKey
+}
+
+class A {
+  def PrimaryKey: Any = ???
+
+  {
+    import ColumnOption._
+
+    (null: Any) match { case PrimaryKey => }
+
+    PrimaryKey // was already ambigious in 2.10.3
+  }
+}
+