RFR 8202372: Diagnostic with incorrect line info generated when compiling lambda expression

[Maurizio Cimadamore]

Good catch - turns out there's a bug in my jtreg IntelliJ plugin that is 
causing this :-)

If it's ok, I will fix the bogus occurrences as part of this commit 
(with no followup review).

Let me know if that's ok.

Maurizio


On 02/05/18 13:15, Jan Lahoda wrote:
> In:
> test/langtools/tools/javac/lambda/8202372/T8202372.java
>
> There is a typo:
>
> nodynamioccopyright
> =>
> nodynamiccopyright
>
> (there appears to be a handful of more occurrences of the typo in a 
> handful of other files:
> test/langtools/tools/javac/lvti/T8200199.java
> test/langtools/tools/javac/lvti/badTypeReference/BadTypeReference.java
> test/langtools/tools/javac/preview/classReaderTest/Client.java
> )
>
> Otherwise looks good to me.
>
> Jan
>
> On 2.5.2018 14:00, B. Blaser wrote:
>> Looks good!
>>
>> Cheers,
>> Bernard
>>
>> On 2 May 2018 at 13:19, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>>> Hi,
>>> I put together a webrev based on the fix that B. Blaser put together 
>>> few
>>> days ago. I've enhanced the test as I realized that the erroneous 
>>> condition
>>> could present in multiple situations (the patch seems to fix all of 
>>> them).
>>>
>>> The underlying issue is that when we create a fake block for the lambda
>>> expression (which is needed for speculatively check its contents), 
>>> we forget
>>> setting its position - meaning that all diags reported against the 
>>> rewritten
>>> block will now appear off sync.
>>>
>>> One solution would be to tweak the code to never use speculative 
>>> trees to
>>> report diagnostic - but that would be very invasive; a cheaper fix 
>>> (the one
>>> attempted here) is to add the required positional info to the 
>>> rewritten tree
>>> so that it matches the original position.
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/8202372/
>>>
>>> Cheers
>>> Maurizio
>>>