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