RFR: JDK-8203277: preflow visitor used during lambda attribution shouldn't visit class definitions inside the lambda body

Vicente Romero vicente.romero at oracle.com
Thu Nov 8 00:24:31 UTC 2018


Please review the fix for [1] at [2]. The bug can be illustrated with 
this test case:

import java.util.List;
import java.util.function.Function;

class DiamondInsideLambdaTest {
     void build() {
         List<Function<String, Double>> list = transform(null,
                 builder -> new Function<>() {
                     public Double apply(String params) { return null; }
                 });
     }

     static <Argument, Result> List<Result> transform(List<Argument> 
fromList, Function<? super Argument,? extends Result> function) { return 
null; }
}

During lambda attribution, there is a preflow visitor that fill some 
holes, missing types / symbols, before doing an special flow analysis on 
the lambda. This flow analysis skip inner classes defined inside the 
lambda body. The preflow visitor is anyway visiting inner classes and 
filling, with garbage, some of the wholes. In most cases as the preflow 
step happens after the lambda body has been attributed, it should be a 
no-op. But if the lambda body contains a diamond as in this case, then 
it could be that the attribution can't be done previous to the preflow 
step. Simply because some types in the diamond could be waiting for type 
inference to come to a resolution. In that case preflow will modify the 
diamond expression and later on during completion, as some symbols and 
types are filled with erroneous types, they will keep that erroneous type.

[1] https://bugs.openjdk.java.net/browse/JDK-8203277
[2] http://cr.openjdk.java.net/~vromero/8203277/webrev.00/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181107/fb092b38/attachment.html>


More information about the compiler-dev mailing list