RFR: JDK14-8236005: local records shouldn't capture any non-static state from any enclosing type
Vicente Romero
vicente.romero at oracle.com
Tue Jan 14 03:37:31 UTC 2020
I will add a test in the lines of:
class Outer<T> {
void m() {
record R(T t) {}
}
}
to the patch
Thanks,
Vicente
On 1/13/20 4:05 PM, Maurizio Cimadamore wrote:
>
> Maybe too late but we might want to add a test for type-variables -
> e.g. accessing enclosing type-variables should equally be banned.
>
> Maurizio
>
> On 13/01/2020 17:46, Vicente Romero wrote:
>>
>>
>> On 1/13/20 9:46 AM, Maurizio Cimadamore wrote:
>>>
>>> Thanks for the explanation. I've convinced myself that the code is
>>> correct. Basically, if we're trying to access a local variable
>>> defined in a method whose class is != than the current class && the
>>> current class is also static (which can only happen with records, as
>>> that's the only local construct which can also be static), an error
>>> should be issued.
>>>
>>
>> cool thanks,
>>
>>> Maurizio
>>>
>>
>> Vicente
>>
>>> On 13/01/2020 13:39, Vicente Romero wrote:
>>>>
>>>>
>>>> On 1/10/20 8:02 PM, Maurizio Cimadamore wrote:
>>>>>
>>>>>
>>>>> On 10/01/2020 22:53, Vicente Romero wrote:
>>>>>> but this code is accepted:
>>>>>>
>>>>>> class R {
>>>>>> void m() {
>>>>>> int z = 0;
>>>>>> record RR(int x) { public int x() { return z; }};
>>>>>> }
>>>>>> }
>>>>>
>>>>> Why is this accepted? Isn't capture of locals also disabled, as
>>>>> demonstrated in the test:
>>>>>
>>>>> // Cant capture locals
>>>>> + assertFail("compiler.err.non-static.cant.be.ref",
>>>>> + "class R { \n" +
>>>>> " void m(int y) { \n" +
>>>>> " record RR(int x) { public int x() { return y; }};\n" +
>>>>> " }\n" +
>>>>> "}");
>>>> sorry I should have been more specific. When I said: "with the
>>>> current conditions" in my previous mail I should had said: "with
>>>> current state without the patch this code is accepted" that's what
>>>> I meant. Without the patch access to non-static fields from records
>>>> are banned but access to local variables is not. This patch is
>>>> closing that last gap
>>>>
>>>> Vicente
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200113/bbfe256f/attachment.htm>
More information about the compiler-dev
mailing list