SI-8143 Regressions with override checks, private members

These regressed in e609f1f20b, which excluded all private methods from
overriding checks. We should only exclude private[this] members on the
low end of a pair, as was done before that commit, and, we must also
exclude private members on the high side.

Why? Warning: reverse engineered intuition follows.

We need to report an error when if a private method in a subclass
has matches a less-private method in the super class and report an
error, lest the user be fooled into thinking it might be invoked
virtually. On the other hand, adding a private method to a super
class shouldn't invalidate the choice names of public members in
its superclasses.

I've removed the test case added by that commit and will lodge a
reworked version of it that Paul provided as a new issue. That shows
a bug with qualified private + inheritance.

In addition, the expectation of `neg/accesses.check` is reverted
to its 2.10.3 version, which I believe is correct. When it was
changed in e609f1f20b it sprouted a variation, `neg/accesses-2`,
which has now changed behaviour. The intent of that test will
be captured in the aforementioned issue covering qualified private
inheritance.

1 files changed, 15 insertions, 0 deletions

diff --git a/test/files/neg/t8143a.scala b/test/files/neg/t8143a.scala
new file mode 100644
index 0000000000..4ec539e671
--- /dev/null
+++ b/test/files/neg/t8143a.scala
@@ -0,0 +1,15 @@
+class Foo { def f = 5 }
+class Bar extends Foo { private def f = 10 }
+
+
+class Foo1 { private def f = 5 }
+class Bar1 extends Foo1 { def f = 10 } // okay
+
+class Foo2 { private def f = 5 }
+class Bar2 extends Foo2 { private def f = 10 } // okay
+
+class Foo3 { private[this] def f = 5 }
+class Bar3 extends Foo3 { private def f = 10 } // okay
+
+class Foo4 { private def f = 5 }
+class Bar4 extends Foo4 { private[this] def f = 10 } // okay
\ No newline at end of file