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

[Vicente Romero]

On Tue, 12 Jul 2022 02:34:00 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> test/langtools/tools/javac/Diagnostics/compressed/T8012003b.out line 4:
>> 
>>> 2: T8012003b.java:31:16: compiler.err.prob.found.req: (compiler.misc.stat.expr.expected)
>>> 3: T8012003b.java:32:22: compiler.err.prob.found.req: (compiler.misc.incompatible.ret.type.in.lambda: (compiler.misc.conditional.target.cant.be.void))
>>> 4: T8012003b.java:33:12: compiler.err.prob.found.req: (compiler.misc.invalid.mref: kindname.method, (compiler.misc.cant.apply.symbol: kindname.method, g, java.lang.String, java.lang.Integer, kindname.class, T8012003b, (compiler.misc.no.conforming.assignment.exists: (compiler.misc.inconvertible.types: java.lang.Integer, java.lang.String))))
>> 
>> Seems like this diagnostic is not getting compressed?
>
> yep good catch, checking what's going on

I have been debugging and analyzing what is happening here, now we are creating more detailed diags compared to the previous code which was basically creating compact diags and they were making it to the corresponding `MethodResolutionContext::candidates` list, so we were selecting a compact diags from the `candidates` list and using a compact diags to issue the error message. Now we are always creating more detailed diags which sometimes link to a compact diags and sometimes don't as we create a lot of diags. This is the reason we are printing a detailed message in this case. One possible solution could be to try to propagate the compact diag, if a detailed diagnostic has one, and we create a new one but I think that if we do this then probably there is no reason to actually create a detailed diagnostic if a compact one is available, which is what the current code is doing.

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

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