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

[Maurizio Cimadamore]

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/9d3f3b68/attachment.htm>