RFR: JDK-8203277: preflow visitor used during lambda attribution shouldn't visit class definitions inside the lambda body
Vicente Romero
vicente.romero at oracle.com
Thu Nov 8 00:24:31 UTC 2018
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/20181107/fb092b38/attachment.html>
More information about the compiler-dev
mailing list