RFR: JDK-8246486: javac doesn't allow a subclass to be declared before a sealed superclass with no permits clause

[Maurizio Cimadamore]

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/16353d3f/attachment.htm>