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

[Vicente Romero]

On 11/8/18 6:02 PM, Maurizio Cimadamore wrote:
>
> 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?
>

right I agree with you, what about [3]?

> Maurizio
>
Vicente

[3] http://cr.openjdk.java.net/~vromero/8203277/webrev.01/
>
> 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/23266f92/attachment.html>