diff options
author | Jason Zaugg <jzaugg@gmail.com> | 2014-01-12 18:12:29 +0100 |
---|---|---|
committer | Jason Zaugg <jzaugg@gmail.com> | 2014-01-14 09:00:05 +0100 |
commit | 2524fdde3edc7b668fdb4bf68e990141d3ec18d6 (patch) | |
tree | 61a99c3191b26f58d1404e1463ae4a90a807ae14 /test/files/neg/t562.check | |
parent | e089cafb5fd02e2457bafde3252da3a771d3180e (diff) | |
download | scala-2524fdde3edc7b668fdb4bf68e990141d3ec18d6.tar.gz scala-2524fdde3edc7b668fdb4bf68e990141d3ec18d6.tar.bz2 scala-2524fdde3edc7b668fdb4bf68e990141d3ec18d6.zip |
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.
Diffstat (limited to 'test/files/neg/t562.check')
0 files changed, 0 insertions, 0 deletions