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

[Maurizio Cimadamore]

Hi,
I agree that preflow shouldn't care about nested constructs; but I 
wonder - is diamond anon class the only case we need to worry about 
here? What about a nested lambda expression?

Maurizio

On 08/11/2018 00:24, Vicente Romero wrote:
> 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/20181108/beecca74/attachment.html>