RFR: 8255968: Confusing error message for inaccessible constructor

[Maurizio Cimadamore]

On Mon, 23 Nov 2020 15:22:26 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information.
> This patch solves this bug, regardless of the construction order, compiler can always output expected message.
> Thank you for taking the time to review.
> 
> Best Regards.

While I somewhat sympathize with the problem you are trying to solve, note that, by doing this, the output of the compiler will regress in case where not _all_ the overload candidates are not accessible. E.g.

m(1): //client

m();
private m(int);

In this case I guess it's less clear as what "should" happen: does the user want to call the first, or second version of `m` ? Both cases are possible - e.g. the user might accidentally call the private version of some method (in which the compiler is right in pointing out that the callsite is wrong), or the user indeed might want to access the private method (in which case your patch to shift the focus onto the access error might seem more appropriate).

I'm a bit skeptical that there exist a silver bullet for these kind of mixed cases. Technically speaking, from a JLS perspective, non-accessible methods should not even take place in overload resolution - so the current compiler behavior is cases where both accessible and inaccessible methods are present seems more appropriate.

In other words, if we really want to improve the status quo, we should detect cases where _all_ candidates are not accessible. Or, we should question whether javac's behavior of tagging inaccessible methods with the kind `WRONG_MTH`/`WRONG_MTHS` is correct in the first place.

It would be nice, I guess, if we could make the inaccessible error more powerful, so that we could keep adding inaccessble symbols as we go along, so that javac could display something like "cannot resolve symbol `m` - but some inaccessible symbols have been found <list>".

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

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