RFR: 8255968: Confusing error message for inaccessible constructor

[Maurizio Cimadamore]

On Tue, 24 Nov 2020 11:44:06 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> 
> I implement this unified format and test the feature locally. @mcimadamore If you agree with these unified output messages, I would update my code for reviewing.

This seems a good direction - but there are few dragons in there. As I said in my previous message, inaccessible members are just not overload resolution candidates and are "skipped" over by the overload selection logic. This is visible in examples like these:

class Sup {
   private void m(String s);
}

class Outer {
     void m() { ... }
     void m(Integer s) { ... }

     class Inner extends Sup {
          void test() {
               m();
           }
      }
}
In this example, overload selection should look for `m` candidates inside the `Outer` class. If, with a patch, you make access errors more similar to `WRONG_MTH`, or `WRONG_MTHS` kinds (by unifying them) chances are that overload selection will start thinking that it found a candidate in `Sup` and stop there - which would be against the JLS. I'm not saying it cannot be done, but more that it has to be done in a careful way - that is, you can only unify the error messages in situation where you know there's a mix of inaccessible and inapplicable methods, so you know already that overload selection will stop at that class.

Another aspect to look out for/test is method references - whatever we say here for plain method calls, has to hold for method reference selection - so you'll want to create specific tests which aims at showing that whatever change is applied, it also improves the situation with method references (or at least does not cause unwanted regressions there).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1389