RFR: JDK-8042981: Strip type annotations in Types' utility methods

Srikanth Adayapalam sadayapalam at openjdk.org
Fri Jun 24 07:49:53 UTC 2022


On Thu, 2 Jun 2022 01:09:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

I think one point of view is to say com.sun.tools.javac.code.Type.Visitor is missing a method, say


R visitPrimtiveType(JCPrimitiveType t, S s);


but really the current method


R visitType(Type t, S s);


serves as the catch all clause, so to speak.

Is it a good enough catch all or does the current problem at hand calls for a discriminating/distinguishing special case method for primitive types is a question.

I think the real problem stems from (a) com.sun.tools.javac.code.Types.MapVisitor#visitType method being idempotent: 

``` 
public Type visitType(Type t, S s) { return t; }


AND

the visitor com.sun.tools.javac.code.Type#stripMetadata's failing to override that method thereby leaving it to the superclass's idempotent implementation to be the implementation.

If I add the following method to com.sun.tools.javac.code.Type#stripMetadata, the failing test passes:


            @Override
            public Type visitType(Type t, Void aVoid) {
                return super.visitType(t.typeNoMetadata(), aVoid);
            }

-------------

PR: https://git.openjdk.org/jdk/pull/8984


More information about the compiler-dev mailing list