RFR 8203488: Remove error generation from TransTypes
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Mon May 21 17:30:01 UTC 2018
Hi,
as written in the bug report, TransTypes generates two kind of
user-facing errors:
1) bridge clash
2) arity mismatch due to sig poly invocation with -target 6
We can simply get rid of (1) as we now have Attr checking that
override/hide do not clash. We can also get rid of (2), by reworking the
fix that introduced it (JDK-8013179
<https://bugs.openjdk.java.net/browse/JDK-8013179>). The issue there was
that, when compiling code that contained a call to MethodHandle.invoke,
with target -6, the compiler was left in a limbo between polysig methods
(which have sharp signatures) and the underlying Java vararg signature
(which is not sharp at all). Since the target method was a 'varargs' but
the call itself was not a varargs call, javac complained about an arity
mismatch.
The solution to this problem is to either use polysig type-checking or
regular type-checking depending on whether the support is enabled in the
backend. If a polysig call is treated as a true polysig call, we emit a
symbol with a sharp descriptor, set the resolution phase to BASIC (no
varargs, no boxing) and we just treat it as a regular call from there
on. This simplified a number of places (e.g. Attr.checkId and
LambdaToMethod) where we needed to special case polysig methods.
If backend support for polysig method is disabled (-target 6), then we
treat a polysig method as a varargs method; meaning that we leave
resolution phase as VARARGS, and then javac will do regular vararg
conversion (e.g. box arguments into an array and pass that to the
method). This of course doesn't make much sense for polysig methods such
as MethodHandle.invoke, but the user gets what he's asking for by
compiling code that has polysig call using a target that doesn't know
what polysig methods even are.
Of course, same code would fail to compile if using --release 6 (as
MethodHandle API was not there in 6).
Webrev:
http://cr.openjdk.java.net/~mcimadamore/8203488/
Maurizio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180521/c6f9b0ca/attachment-0001.html>
More information about the compiler-dev
mailing list