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

[Maurizio Cimadamore]

Looks good - why is there a new change in the test?

Maurizio

On 19/11/2018 20:57, Vicente Romero wrote:
> Hi Maurizio,
>
> On 11/9/18 5:57 AM, Maurizio Cimadamore wrote:
>>
>> Looks good - can we cook up a test that is also stressing the other 
>> new code path?
>>
>
> what about: http://cr.openjdk.java.net/~vromero/8203277/webrev.02/?
>
>> Maurizio
>>
>
> Thanks,
> Vicente
>
>> On 09/11/2018 00:12, Vicente Romero wrote:
>>>
>>>
>>> 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/20181120/3a35a0a5/attachment-0001.html>