8269121: Type inference bug with method references #5406
Conversation
|
👋 Welcome back vromero! A progress list of the required criteria for merging this PR into |
|
@vicente-romero-oracle The following label will be automatically applied to this pull request:
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. |
Webrevs
|
There was a problem hiding this 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) { |
There was a problem hiding this comment.
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.
|
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 |
|
|
|
@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! |
|
@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 |
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
Issue
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5406/head:pull/5406$ git checkout pull/5406Update a local copy of the PR:
$ git checkout pull/5406$ git pull https://git.openjdk.java.net/jdk pull/5406/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 5406View PR using the GUI difftool:
$ git pr show -t 5406Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5406.diff