RFR: JDK14-8236005: local records shouldn't capture any non-static state from any enclosing type

[Maurizio Cimadamore]

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/689b4b43/attachment.htm>