RFR 8169345: javac crash when local from enclosing context is captured multiple times
B. Blaser
bsrbnd at gmail.com
Sat Oct 7 14:59:41 UTC 2017
Looks good to me, too.
I noticed you used an index to differentiate the proxies which is
better than simply incorporating the name of the owner as I suggested
in [3] as some name clash might also occur...
Thanks,
Bernard
[3] http://mail.openjdk.java.net/pipermail/compiler-dev/2017-February/010794.html
On 6 October 2017 at 18:46, Vicente Romero <vicente.romero at oracle.com> wrote:
> Looks good,
>
> Thanks,
> Vicente
>
>
> On 10/06/2017 10:39 AM, Maurizio Cimadamore wrote:
>>
>> Hi,
>> this patch fixes an issue regarding how Lower handles captured variables
>> from enclosing scopes. Quoting from my analysis in JBS [1]:
>>
>> class Main {
>> void test () {
>> Object o = new Object();
>> class Local1 {
>> Object test1() { return o; }
>> }
>> class Local2 {
>> void test2() {
>> Object o = new Object();
>> class Local3 extends Local1 {
>> Object test3() { return o; }
>> }
>> }
>> }
>> }
>> }
>>
>> Here, class Local3 captures 'o' from:
>>
>> * Main::test (this capture is necessary, as the superclass constructor
>> (for Local1) will need to take that 'b'
>> * Local2::test2 (this capture is necessary as that's the variable
>> referenced to by the Local3::test3 method)
>>
>> This ends up breaking many invariants inside Lower, as:
>>
>> * Lower represents all captured variables using a simple encoding such as
>> 'val' $ 'varname' - meaning that both captured variables above end up as
>> 'val$o'. This will cause issues when looking up the variable - which is
>> currently done with a named scope lookup (find first).
>>
>> * Lower.initField assumes that there's only one (synthetic) parameter
>> named 'val$o' in the lowered constructor declaration and it also assumes
>> that there's only one (synthetic) field in the local with the same name.
>> This correspondency allows Lower to generate the synthetic field initializer
>> by relying on scope properties.
>>
>>
>> Here's the webrev:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8169345/
>>
>> Note - this has been briefly discussed in [2].
>>
>> Cheers
>> Maurizio
>>
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8169345
>> [2] -
>> http://mail.openjdk.java.net/pipermail/compiler-dev/2017-February/010790.html
>>
>>
>
More information about the compiler-dev
mailing list