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

[Vicente Romero]

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/20181119/2d8afb45/attachment-0001.html>