[PATCH] Diagnostic position fix for statement-bodied lambdas

[Liam Miller-Cushon]

Thanks Vicente. There's no rush, I just wanted to make sure it didn't get
lost.

On Thu, Jan 22, 2015 at 10:10 AM, Vicente-Arturo Romero-Zaldivar <
vicente.romero at oracle.com> wrote:

>  Hi Liam,
>
> The bug is a P4, so it's only blocked for other bugs / projects with
> higher priority I'm working on. I will take a look at it later this week,
>
> Thanks,
> Vicente
>
>
> On 01/16/2015 05:19 PM, Liam Miller-Cushon wrote:
>
> Sorry, I lost track of this. Is the patch blocked on anything at my end?
>
> On Mon, Nov 24, 2014 at 11:04 AM, Vicente-Arturo Romero-Zaldivar <
> vicente.romero at oracle.com> wrote:
>
>>  Hi Liam,
>>
>> I have created this bug entry:
>> https://bugs.openjdk.java.net/browse/JDK-8065800 to track this issue.
>>
>> Thanks,
>> Vicente
>>
>>
>> On 11/17/2014 11:14 AM, Vicente-Arturo Romero-Zaldivar wrote:
>>
>> Hi Liam,
>>
>> I don't know of any reason to use the position of the arguments as the
>> position of the lambda body. I will sponsor your patch,
>>
>> Thanks,
>> Vicente
>>
>> On 11/14/2014 05:16 PM, Liam Miller-Cushon wrote:
>>
>> When parsing statement-bodied lambda expressions, javac currently uses
>> the start position of the parameter list for the body. This patch fixes the
>> parser to record the body's start position correctly.
>>
>> Example diagnostic before this change:
>>
>> Test.java:17: error: incompatible types: bad return type in lambda
>> expression
>>         foo((x) -> { return ""; System.out.println(""); });
>>             ^
>>
>> After:
>>
>> Test.java:17: error: lambda body is neither value nor void compatible
>>         foo((x) -> { return ""; System.out.println(""); });
>>                    ^
>>
>> Placing the caret at the parameter list may be deliberate, but it should
>> be possible to do that without recording the body's start position
>> incorrectly.
>>
>> Thanks,
>> Liam
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150122/bbe0fd8f/attachment.html>