RFR JDK-8131915: CompletionFailure during import listing crashes javac

[Maurizio Cimadamore]

Looks great!

I guess in TypeEnter you could go either with a lambda or a method 
reference (given that tree.pos() == tree); but if you go down the method 
reference path, I believe you can have issues if 'chk' is null when the 
initializer is evaluated, so a lambda seems generally safer here - 
albeit slightly less direct.

Maurizio

On 31/07/15 12:36, Jan Lahoda wrote:
> Thanks for the comments.
>
> Based on additional offline feedback, I tried to use 
> "BiConsumer<JCImport, CompletionFailure>" instead of 
> "Consumer<CompletionFailure>" - the advantage is that the lambda does 
> not need to capture the JCImport. The FilterImportScope however needs 
> to keep the JCImport, instead of the current "staticImport" boolean flag.
>
> A webrev with these changes is here:
> http://cr.openjdk.java.net/~jlahoda/8131915/webrev.01/
>
> This new state seems reasonable to me. What do you think?
>
> (I've also fixed the bug # in the new iteration and added a summary to 
> the CompletionFailureDuringImport test.)
>
> Thanks,
>    Jan
>
> On 30.7.2015 13:41, Maurizio Cimadamore wrote:
>> Whoops - hit send too soon.
>>
>> The new tests need the new bug id in the header.
>>
>> Maurizio
>>
>> On 30/07/15 12:38, Maurizio Cimadamore wrote:
>>> Looks great.
>>>
>>> Maurizio
>>>
>>> On 24/07/15 15:03, Jan Lahoda wrote:
>>>> Hello,
>>>>
>>>> This is a fix for:
>>>> https://bugs.openjdk.java.net/browse/JDK-8131915
>>>>
>>>> which Liam reported recently. The problem is that if a
>>>> CompletionFailure happens while listing import content (e.g. due to a
>>>> missing supertype), it is not handled properly and causes a javac 
>>>> crash.
>>>>
>>>> The proposed fix is to catch the CompletionFailure and handle it
>>>> properly (log an error).
>>>>
>>>> A webrev with the fix is here:
>>>> http://cr.openjdk.java.net/~jlahoda/8131915/webrev.00/
>>>>
>>>> Any feedback is welcome,
>>>>
>>>> Thanks!
>>>>     Jan
>>>
>>