Improved the error message for another of the m...

Improved the error message for another of the most common situations
I hear about in newbieland. It could be taken further. If compilation
fails due to an unimplemented abstract method, and there is a concrete
method of the same name and arity, it will do a pairwise analysis of the
parameters and attempt to further explain where you went off the beam if
it feels it can do so sensibly. Such as in the test case:

  % scalac S.scala
  S.scala:1: error: class S needs to be abstract, since method g in class J of type (y: Int,z: java.util.List)Int is not defined
  (Note that java.util.List does not match java.util.List[String]. To implement a raw type, use java.util.List[_])
  class S extends J {
        ^
  one error found

No review.

2 files changed, 8 insertions, 0 deletions

diff --git a/test/files/neg/abstract-class-error/J.java b/test/files/neg/abstract-class-error/J.java
new file mode 100644
index 0000000000..5877f5cc5b
--- /dev/null
+++ b/test/files/neg/abstract-class-error/J.java
@@ -0,0 +1,4 @@
+public abstract class J {
+  public abstract int f();
+  public abstract int g(int y, java.util.List z);
+}
\ No newline at end of file
diff --git a/test/files/neg/abstract-class-error/S.scala b/test/files/neg/abstract-class-error/S.scala
new file mode 100644
index 0000000000..67f6d8593e
--- /dev/null
+++ b/test/files/neg/abstract-class-error/S.scala
@@ -0,0 +1,4 @@
+class S extends J {
+  def f() = 55
+  def g(y: Int, z: java.util.List[String]) = 11
+}