RFR: 8268312: Compilation error with nested generic functional interface [v4]

Maurizio Cimadamore mcimadamore at openjdk.org
Thu Jul 7 10:09:48 UTC 2022


On Thu, 7 Jul 2022 09:56:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Merge master
>>  - addressing another review iteration
>>  - addressing review comments
>>  - 8268312: Compilation error with nested generic functional interface
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 4181:
> 
>> 4179:             return diags.create(dkind, log.currentSource(), pos,
>> 4180:                       "cant.apply.symbol",
>> 4181:                       d -> MethodResolutionDiagHelper.rewrite(diags, pos, log.currentSource(), dkind, c.snd),
> 
> This is a good step in the right direction - e.g. attaching a rewriting function to the diagnostic object itself. I wonder if a simpler solution is possible, as I note here that the call to `rewrite` is basically just passing info that are attached to the diagnostic being created _plus_ `c.snd` which is the real new bit of info.
> 
> E.g. in principle, we could just create the new diagnostic with a "cause" (e.g. `c.snd`) and then, when we're about to report the diagnostic, we check if there's a cause set and, if so, we try to late-rewrite the diagnostic. If we do this, perhaps we might be able to avoid the creation of a new instance in a very hot path.

I would also check for other usages of the rewriter framework and make sure they follow the same pattern - right now we have some diagnostics using the late-bound reporting mechanism (such as this), and others (e.g. diamond, but possibly other inference ones as well) which rewrite the diagnostic eagerly. We should try to have only one way to do things. My feeling is that diagnostic rewriting should be a general mechanism, not something that belongs in Resolve (but perhaps closer to Log).

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

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


More information about the compiler-dev mailing list