RFR: JDK-8246486: javac doesn't allow a subclass to be declared before a sealed superclass with no permits clause
Vicente Romero
vicente.romero at oracle.com
Thu Jun 4 23:01:46 UTC 2020
thanks for the review, I will update the code with your proposed change
before pushing
Vicente
On 6/4/20 5:28 PM, Maurizio Cimadamore wrote:
>
> Hit "send" too fast - small tweak suggested - instead of:
>
> sym.permitted = !permittedSubtypeSymbols.isEmpty() ?
> + permittedSubtypeSymbols.toList() :
> + sym.permitted;
> Just go for:
>
> if (!permittedSubtypeSymbols.isEmpty()) { sym.permitted =
> permittedSubtypeSymbols.toList(); }
>
> Maurizio
>
> On 04/06/2020 22:24, Maurizio Cimadamore wrote:
>>
>> Changes look good.
>>
>> Maurizio
>>
>>
>> On 03/06/2020 21:22, Vicente Romero wrote:
>>> Please review the fix for [1] at [2], this patch if fixing the
>>> following issue, javac doesn't accept code like:
>>>
>>> final class B extends A {}
>>> sealed class A {} // no permits clause
>>>
>>> the reason is that when analyzing the permits clause of the sealed
>>> class, the permitted list was overwritten without checking if it
>>> wasn't empty. This is fixed now. Also as the presence of annotation
>>> processors can provoke several iterations on the same code, now it
>>> is necessary to clean out the `permitted` list if annotations
>>> processors are present. This avoid that an iteration can find
>>> symbols stored in this list by a previous iteration. Given this new
>>> dependency on annotation processors of the sealed classes code, test
>>> SealedCompilationTests has been modified to be executed twice: with
>>> and without a simple annotations processor to stress this
>>> dependency. There is a change that is not strictly related to the
>>> main theme of the patch which is this one liner:
>>>
>>> diff -r 0a32396f7a69 -r 3a73b52df56b
>>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java
>>> ---
>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java
>>> Wed Jun 03 12:09:04 2020 -0400
>>> +++
>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java
>>> Wed Jun 03 15:25:41 2020 -0400
>>> @@ -717,7 +717,6 @@
>>> ListBuffer<Symbol> permittedSubtypeSymbols = new
>>> ListBuffer<>();
>>> List<JCExpression> permittedTrees = tree.permitting;
>>> for (JCExpression permitted : permittedTrees) {
>>> - permitted = clearTypeParams(permitted);
>>> Type pt = attr.attribBase(permitted, baseEnv,
>>> false, false, false);
>>> permittedSubtypeSymbols.append(pt.tsym);
>>> }
>>>
>>> permitted subclasses can't have type parameters thus this line is a
>>> no-op, but given that the bug was related to the permits clause I
>>> found this issue and addressed it as part of the patch,
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8246486
>>> [2] http://cr.openjdk.java.net/~vromero/8246486/webrev.00/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200604/bc23aba3/attachment-0001.htm>
More information about the compiler-dev
mailing list