RFR: JDK-8205418: Assorted improvements to source code model

[Maurizio Cimadamore]

Looks very good. I think esp. the changes in Resolve will help in 
getting more consistent diagnostics in the compiler.

P.S.

Since we're looking here - there is a long-standing issue in resolution 
errors that I think should be addressed (not as part of this fix of 
course): whenever there's an ambiguous call, javac picks one of the two 
methods as the result of overload selection, and this can lead to 
spurious downstream diagnostics - consider the following example:

class Amb {

     String m(int i1, Integer i2) { return ""; }

     int m(Integer i1, int i2) { return 32; }

     void test() {

          int i = m(42, 42);
     }

}

This gives the following errors:

Amb.java:9: error: reference to m is ambiguous
          int i = m(42, 42);
                  ^
   both method m(int,Integer) in Amb and method m(Integer,int) in Amb match

Amb.java:9: error: incompatible types: String cannot be converted to int
          int i = m(42, 42);
                   ^
2 errors

As you can see, the first one is genuine, the second is spurious, and 
order-dependent.

Maurizio


On 25/06/18 15:55, Jan Lahoda wrote:
> Thanks for all the comments.
>
> I've updated the patch according to the comment, and uploaded the new 
> patch here:
> http://cr.openjdk.java.net/~jlahoda/8205418/webrev.01/
>
> (For the RecoveryInfo.CheckContext.report, I've disabled the errors 
> only when the new recovery is active, which should limit the effects 
> on error messages.)
>
> Any feedback is welcome!
>
> Thanks,
>     Jan
>
> On 22.6.2018 14:37, Maurizio Cimadamore wrote:
>>
>>
>> On 22/06/18 13:32, Maurizio Cimadamore wrote:
>>> When messages are simplified, basically we turn errors into other
>>> errors - e.g. look at InapplicableSymbol_S_Error::getDiagnostic -
>>> there is some logic and then, if there's really onlt one relevant
>>> candidate, we go back to an InapplicableSymbol (without S) error,
>>> where 'errCandidate' is overridden to return the filtered symbol.
>>>
>>> Another reason to rely more on errCandidate
>> More specifically, if simplified diagnostics are disabled, you go remain
>> in the multiple symbols world, which means you still have more
>> candidates and you fail to see that only one was really the good one.
>>
>> So, I think InapplicableSymbolsError should override bestCandidate
>> (which I also suggested in previous email), and should call
>> filterCandidates before doing the processing. This will ensure that
>> 'redundant' candidates are dropped, and you get back the symbol that is
>> most likely to be the correct one.
>>
>> Maurizio
>>