RFR: 8295019: Cannot call a method with a parameter of a local class declared in a lambda
Vicente Romero
vromero at openjdk.org
Tue Jan 31 05:44:42 UTC 2023
Very interesting and, a bit tricky, bug. So the compiler is rejecting code like:
class LocalClassDeclaredInsideLambdaTest {
void run(Runnable r) {}
void m() {
run(() -> {
class C {
static void takeC(C c) {}
static C giveC() {
return null;
}
}
C.takeC(C.giveC());
});
}
}
with error:
LocalClassInsideLambda.java:12: error: incompatible types: C cannot be converted to C
C.takeC(C.giveC());
^
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
1 error
which is very misleading as the type seems to be the same. The issue here is that both the lambda and invocation `C.giveC()` are considered poly expressions. `C.giveC()` is not a poly expression but at the moment the compiler is analyzing if an invocation is a poly expression or not, it doesn't have enough information and errs on the safe side.
We have a cache at `com.sun.tools.javac.comp.ArgumentAttr`, see field `argumentTypeCache`, which stores the current deferred type of arguments considered poly expressions. The problem with this particular code is that inside of the lambda there is a class declaration and every time the lambda is attributed a new class type is created.
The lambda, and thus the expression `C.giveC()` are attributed twice. The first time we have an speculative attribution, as a result `argumentTypeCache` will have two entries, one for the lambda and one for `C.giveC()` but the type of `C` is the type created during speculative attribution on a copy of the original lambda tree, let's call it C1. Later on another pass the lambda is attributed `"for real"`, during the check phase. At this point the entry for the lambda in the cache pointed by `argumentTypeCache` has been removed but there is still the entry for `C.giveC()` which still refers to `C1`. So now in the `"for real"` attribution of the lambda which happens on the original tree, not in a copy, a new type for class `C` is created, let's call it `C2`. But when we get to the point where we need to attribute again `C.takeC(C.giveC())` invocation `C.takeC` is expecting `C2` but as `C.giveC()` is again considered a poly expression and an entry is found for it at the cache, the compil
er reuses that entry which refers to `C1`. And unfortunately `C1 != C2` and thus the error is issued. So the solution I propose is to use a local cache for the speculative attribution of lambda expressions. This is a one liner fix, although an alternative solution could be to scan the lambda body and only use a local cache if a new type is defined inside the lambda, this could be a more optimal solution performance wise as we could save some attributions in some cases. Comments?
TIA
-------------
Commit messages:
- updating test name
- 8295019: Cannot call a method with a parameter of a local class declared in a lambda
Changes: https://git.openjdk.org/jdk/pull/12303/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12303&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8295019
Stats: 65 lines in 2 files changed: 64 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/12303.diff
Fetch: git fetch https://git.openjdk.org/jdk pull/12303/head:pull/12303
PR: https://git.openjdk.org/jdk/pull/12303
More information about the compiler-dev
mailing list