RFR: 8267312: Resolve should use generated diagnostic factories

Maurizio Cimadamore mcimadamore at openjdk.java.net
Tue May 18 12:22:51 UTC 2021


On Tue, 18 May 2021 11:07:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch allows Resolve to use more static diagnostic factories. Resolution errors support generation of diagnostics. This generation is very flexible and allows creating either a toplevel (error or warning) diagnostic, or a nested (fragment) diagostic. To support this, many resolution diagnostics in javac define some "overloads" in compiler.properties - e.g.
> 
> 
> # 0: message segment
> compiler.err.prob.found.req=...
> # 0: message segment
> compiler.misc.prob.found.req=...
> # 0: message segment, 1: type, 2: type
> compiler.warn.prob.found.req=...
> 
> 
> To support switching from one diagnostic kind to another, this patch adds a new method on `DiagnosticInfo`, namely `toType(DiagnosticType)`. The default implementation of this method will simply check that the type is identical to that of the current diagnostic info, and throw otherwise.
> 
> This patch modifies the build-time step to construct diagnostic factories, so that, whenever a diagnostic overload is detected, the `toType` method is overridden, and the right constants/factories are returned/called depending on the requested diagnostic type. For instance, the factory for the `prob.found.req` key will look as follows in the generated code:
> 
> 
> /**
>          * compiler.err.prob.found.req=\
>          *    incompatible types: {0}
>          */
>         public static Error ProbFoundReq(Fragment arg0) {
>             return new Error("compiler", "prob.found.req", arg0) {
>                 public JCDiagnostic.DiagnosticInfo toType(JCDiagnostic.DiagnosticType kind) {
>                     return switch (kind) {
>                         case ERROR -> this;
>                         case WARNING -> throw new AssertionError("Unsupported kind: " + kind);
>                         case FRAGMENT -> Fragments.ProbFoundReq(arg0);
>                         case NOTE -> throw new AssertionError("Unsupported kind: " + kind);
>                     };
>                 }
>             };
>         }
> 
> 
> As you can see, the build time process correctly detects all diagnostic overloads and generate some code to convert one diagnostic info to another. Note that in this case, only two overloads are detected (`err` and `misc`), given that `warn` has a different type comment so not, technically speaking, an overload.
> 
> With this support it is relatively easy to go back to Resolve and update most of the resolution errors to use the generated factories.
> 
> The only case I have not dealt with is the "cannot.resolve" diagnostic, which has many variants: `{ var, method, generic method } x { location, no location }`. To use the factories effectively here a change in the way the diagnostic is structured is required, but doing so, while trivial, will cause many change in the golden test files, so I held off these changes for now, and will come back later to this.

make/langtools/tools/propertiesparser/resources/templates.properties line 53:

> 51:     {0}public static {1} {2}({3}) '{'\n\
> 52:     {4}\n\
> 53:     '}\n'

This could probably just use text blocks and replacements - I'll leave that for another day.

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

PR: https://git.openjdk.java.net/jdk/pull/4089



More information about the build-dev mailing list