Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8269121: Type inference bug with method references #5406

Closed

Conversation

vicente-romero-oracle
Copy link
Contributor

@vicente-romero-oracle vicente-romero-oracle commented Sep 8, 2021

Please review this PR which is making a change to how javac generates the arguments for the lambda metafactory. There are cases like the one described in the JIRA bug entry for which the generated arguments won't be valid and the generated code will fail at execution. The problem arises when the erasure of the lambda method is incompatible with the erasure of the function descriptor. This can happen when at least one of the arguments of the lambda method has an intersection type, in case that the erasure of the intersection type is not compatible with the corresponding argument of the function descriptor. This fix's proposal is to analyze all the components of the intersection and select the first that is compatible with its corresponding argument in the function descriptor.

TIA


Progress

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

Issue

  • JDK-8269121: Type inference bug with method references

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 5406

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

Using diff file

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

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Sep 8, 2021

👋 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 openjdk bot added the rfr label Sep 8, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Sep 8, 2021

@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 openjdk bot added the compiler label Sep 8, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Sep 8, 2021

Copy link
Contributor

@mcimadamore mcimadamore left a comment

Overall, it seems like a good first step. Perhaps worth spending some more time to think if we can find other cases where the erasure of the lambda method type would be incompatible with the erasure of the target function descriptor, and see if we need to make the logic in typeToMethodType more general.

return typeToMethodType(mt, null);
}

private MethodType typeToMethodType(Type mt, MethodType interfaceMethodType) {
Copy link
Contributor

@mcimadamore mcimadamore Sep 8, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is nice that we can put all the complexity in this method. I wonder if we could somehow make this more general - e.g. instead of detecting whether there is an intersection type - simply compare the erased signature of the function descriptor with the erased signature of the lambda method, and see if the two are compatible. I believe that, maybe, a resolution check might work (e.g. try to pass the erased parameter to the erased function descriptor and see if we get a resolution error or not). In Lower we do something similar - see Lower::lookupMethod.

Another option could be to always use the erased function descriptor type, and then add the required casts inside the lambda method implementation body (in most cases there would be no casts) - e.g. do not rely on the conversions handled by the lambda metafactory, but generate code that is more 1-1 with what the metafactory expects (and fix it up on the javac side). But doing this might change signature for some of the lambda bodies - which, if we take into account serializable lambdas, could be problematic.

@vicente-romero-oracle
Copy link
Contributor Author

@vicente-romero-oracle vicente-romero-oracle commented Sep 8, 2021

I found another very related bug in my list: https://bugs.openjdk.java.net/browse/JDK-8259491 I will check if I can kill two with one

@openjdk
Copy link

@openjdk openjdk bot commented Sep 22, 2021

⚠️ @vicente-romero-oracle This pull request contains merges that bring in commits not present in the target repository. Since this is not a "merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of this pull request to Merge <project>:<branch> where <project> is the name of another project in the OpenJDK organization (for example Merge jdk:master).

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Oct 21, 2021

@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
Copy link

@bridgekeeper bridgekeeper bot commented Nov 18, 2021

@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.

@bridgekeeper bridgekeeper bot closed this Nov 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler rfr
2 participants