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

[Maurizio Cimadamore]

Looks good - can we cook up a test that is also stressing the other new 
code path?

Maurizio

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/20181109/7c109c39/attachment.html>