RFR: 8286057: Make javac error on a generic enum friendlier [v2]
Aggelos Biboudis
abimpoudis at openjdk.java.net
Fri May 13 14:31:58 UTC 2022
On Fri, 13 May 2022 11:10:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:
>> Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>>
>> 8286057: Make javac error on a generic enum friendlier
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 4037:
>
>> 4035:
>> 4036: if(typeParametersOpt().size() > 0) {
>> 4037: log.error(DiagnosticFlag.SYNTAX, S.prevToken().endPos, Errors.EnumCantBeGeneric);
>
> I agree with Pavel the location of the error could be better - probably store the `typeParametersOpt` into a variable, and then use the content to provide a better location. Or, you could store some meaningful position based on tokens.
I improved the error position. Now all the following report the same error:
public enum E1<> {}
public enum E2<T> {}
public enum E3<T, T> {}
However, at a cost of a small refactoring in `typeParametersOpt` to allow (erroneous) empty lists of type parameters opt. The new version (the overload with the boolean) can be used if the caller wants to return a more precise error as in this case. The way to communicate this situation to the caller is through a `null` ret list. Despite I noticed that `null` is used in various cases, I am still a bit skeptical if this is the right way (for such small benefit).
WDYT @pavelrappo, @lahodaj
-------------
PR: https://git.openjdk.java.net/jdk/pull/8677
More information about the compiler-dev
mailing list