8268312: Compilation error with nested generic functional interface #5586

vicente-romero-oracle · 2021-09-20T19:00:29Z

Please review this PR, which is my proposal to fix an existing regression. This code:

import java.util.Optional;

class App {
    public static void main(String[] args) {
        Optional.of("").map(outer -> {
            Optional.of("")
                .map(inner -> returnGeneric(outer))
                .ifPresent(String::toString);
            return "";
        });
    }

    private static <RG> RG returnGeneric(RG generic) {
        return generic;
    }
}

is not accepted by javac but if the user passes the -Xdiags:verbose option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at DeferredDiagnosticHandler::report. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the -Xdiags:verbose option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?

TIA

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8268312: Compilation error with nested generic functional interface

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5586/head:pull/5586
$ git checkout pull/5586

Update a local copy of the PR:
$ git checkout pull/5586
$ git pull https://git.openjdk.java.net/jdk pull/5586/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 5586

View PR using the GUI difftool:
$ git pr show -t 5586

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5586.diff

bridgekeeper · 2021-09-20T19:01:08Z

👋 Welcome back vromero! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2021-09-20T19:06:05Z

@vicente-romero-oracle The following label will be automatically applied to this pull request:

compiler

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

openjdk · 2021-09-20T19:06:07Z

@vicente-romero-oracle The following label will be automatically applied to this pull request:

compiler

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2021-09-20T19:12:10Z

Webrevs

01: Full - Incremental (95a0839a)
00: Full (60857430)

vicente-romero-oracle · 2021-09-28T00:52:04Z

ping

mcimadamore

Very tricky issue. Basically, the deferred diagnostic handler checks whether the diagnostic is associated with the tree being speculatively attributed. This is required, because sometimes, when attributing a piece of code, we could have completion events, causing the compiler to jump from one file to another - it is important that completion related issues are logged, even if we're inside deferred attribution, which is why the logic is there.

The resolution diagnostic rewrite throws a spanner in the work though - because it can sometime update the diagnostic position to make it appear like the error was on an outermost node, which then will fall outside the tree covered by the deferred diagnostic handler, and result in spurious errors being generated.

I think a more robust solution would be to leave the diagnostic as is (since the diagnostic handler in DeferredAttr depends on it), but at the same time, maybe record something on the JCDiagnostic object - e.g. like a Supplier which allows the diagnostic to be simplified later, by Log, rather than eagerly, by Resolve. It is possible that, if we do this, we might no longer require a COMPRESSED flag on the diagnostic at all - after all, if Log is in charge of the rewriting, it knows which diagnostics have been touched.

mcimadamore · 2021-09-29T16:02:06Z

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java

+                final DiagnosticPosition pos = d.getDiagnosticPosition();
+                UnaryOperator<JCDiagnostic> rewriter = pos != null ?
+                        diag -> diags.create(preferredKind, preferredSource, pos, "prob.found.req", cause) :
+                        null;
                return diags.create(preferredKind, preferredSource, preferredPos,


I guess here we should return the diagnostic unmodified? E.g. you are still returning a rewritten diagnostic here, the only thing that changes is the position (which is what avoids the bug). What I'm hoping is that we can obtain a new diagnostic (with a rewriter) from an existing diagnostic. See my other comment.

mcimadamore · 2021-09-29T16:02:06Z

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java

@@ -4135,8 +4136,7 @@ JCDiagnostic getDiagnostic(JCDiagnostic.DiagnosticType dkind,

            Pair<Symbol, JCDiagnostic> c = errCandidate();
            if (compactMethodDiags) {


I think what 'm really after here is to drop this branch - e.g. always create the "non compressed" diagnostic (e.g. cannot.apply) with the right position.

But, before returning that, attach a rewriter to it e.g.

Symbol ws = c.fst.asMemberOf(site, types); return diags.create(dkind, log.currentSource(), pos, "cant.apply.symbol", kindName(ws), ws.name == names.init ? ws.owner.name : ws.name, methodArguments(ws.type.getParameterTypes()), methodArguments(argtypes), kindName(ws.owner), ws.owner.type, c.snd).withRewriter(() -> MethodResolutionDiagHelper.rewrite(diags, pos, log.currentSource(), dkind, c.snd));

mcimadamore · 2021-09-29T16:02:06Z

src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java

@@ -1713,9 +1713,6 @@ public void reportDeferredDiagnostics() {
        }
        chk.reportDeferredDiagnostics();
        preview.reportDeferredDiagnostics();
-        if (log.compressedOutput) {


This can be kept, no?

mcimadamore · 2021-09-29T21:18:32Z

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java

@@ -707,9 +705,6 @@ public void report(JCDiagnostic diagnostic) {
                }
                break;
            }
-            if (diagnostic.isFlagSet(JCDiagnostic.DiagnosticFlag.COMPRESSED)) {


Who sets this now?

bridgekeeper · 2021-10-28T04:06:20Z

@vicente-romero-oracle This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

bridgekeeper · 2021-11-25T10:29:19Z

@vicente-romero-oracle This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

vicente-romero-oracle · 2022-01-05T18:56:09Z

/open

openjdk · 2022-01-05T18:56:48Z

@vicente-romero-oracle This pull request is now open

bridgekeeper · 2022-02-02T20:44:45Z

@vicente-romero-oracle This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

bridgekeeper · 2022-03-03T01:38:50Z

@vicente-romero-oracle This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

vicente-romero-oracle · 2022-03-23T16:22:00Z

/open

openjdk · 2022-03-23T16:22:23Z

@vicente-romero-oracle This pull request is now open

vicente-romero-oracle · 2022-03-23T16:24:15Z

/open

openjdk · 2022-03-23T16:25:05Z

@vicente-romero-oracle This pull request is already open

vicente-romero-oracle · 2022-03-23T16:25:31Z

ping

bridgekeeper · 2022-04-20T20:52:16Z

@vicente-romero-oracle This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

bridgekeeper · 2022-05-19T01:45:42Z

@vicente-romero-oracle This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

8268312: Compilation error with nested generic functional interface

6085743

openjdk bot added the rfr label Sep 20, 2021

openjdk bot added the compiler label Sep 20, 2021

mcimadamore reviewed Sep 28, 2021

View changes

addressing review comments

95a0839

mcimadamore reviewed Sep 29, 2021

View changes

bridgekeeper bot closed this Nov 25, 2021

openjdk bot reopened this Jan 5, 2022

bridgekeeper bot closed this Mar 3, 2022

openjdk bot reopened this Mar 23, 2022

bridgekeeper bot closed this May 19, 2022

8268312: Compilation error with nested generic functional interface #5586

8268312: Compilation error with nested generic functional interface #5586

vicente-romero-oracle commented Sep 20, 2021 •

edited by openjdk[bot] bot

bridgekeeper bot commented Sep 20, 2021

openjdk bot commented Sep 20, 2021

openjdk bot commented Sep 20, 2021

mlbridge bot commented Sep 20, 2021 •

edited

vicente-romero-oracle commented Sep 28, 2021

mcimadamore left a comment

mcimadamore Sep 29, 2021

mcimadamore Sep 29, 2021

mcimadamore Sep 29, 2021

mcimadamore Sep 29, 2021

bridgekeeper bot commented Oct 28, 2021

bridgekeeper bot commented Nov 25, 2021

vicente-romero-oracle commented Jan 5, 2022

openjdk bot commented Jan 5, 2022

bridgekeeper bot commented Feb 2, 2022

bridgekeeper bot commented Mar 3, 2022

vicente-romero-oracle commented Mar 23, 2022

openjdk bot commented Mar 23, 2022

vicente-romero-oracle commented Mar 23, 2022

openjdk bot commented Mar 23, 2022

vicente-romero-oracle commented Mar 23, 2022

bridgekeeper bot commented Apr 20, 2022

bridgekeeper bot commented May 19, 2022

		@@ -4135,8 +4136,7 @@ JCDiagnostic getDiagnostic(JCDiagnostic.DiagnosticType dkind,

		Pair<Symbol, JCDiagnostic> c = errCandidate();
		if (compactMethodDiags) {

8268312: Compilation error with nested generic functional interface #5586

8268312: Compilation error with nested generic functional interface #5586

Conversation

vicente-romero-oracle commented Sep 20, 2021 • edited by openjdk[bot] bot

Progress

Issue

Reviewing

bridgekeeper bot commented Sep 20, 2021

openjdk bot commented Sep 20, 2021

openjdk bot commented Sep 20, 2021

mlbridge bot commented Sep 20, 2021 • edited

Webrevs

vicente-romero-oracle commented Sep 28, 2021

mcimadamore left a comment

mcimadamore Sep 29, 2021

Choose a reason for hiding this comment

mcimadamore Sep 29, 2021

Choose a reason for hiding this comment

mcimadamore Sep 29, 2021

Choose a reason for hiding this comment

mcimadamore Sep 29, 2021

Choose a reason for hiding this comment

bridgekeeper bot commented Oct 28, 2021

bridgekeeper bot commented Nov 25, 2021

vicente-romero-oracle commented Jan 5, 2022

openjdk bot commented Jan 5, 2022

bridgekeeper bot commented Feb 2, 2022

bridgekeeper bot commented Mar 3, 2022

vicente-romero-oracle commented Mar 23, 2022

openjdk bot commented Mar 23, 2022

vicente-romero-oracle commented Mar 23, 2022

openjdk bot commented Mar 23, 2022

vicente-romero-oracle commented Mar 23, 2022

bridgekeeper bot commented Apr 20, 2022

bridgekeeper bot commented May 19, 2022

vicente-romero-oracle commented Sep 20, 2021 •

edited by openjdk[bot] bot

mlbridge bot commented Sep 20, 2021 •

edited