RFR 8203488: Remove error generation from TransTypes

[Maurizio Cimadamore]

On 21/05/18 22:48, Liam Miller-Cushon wrote:
> Hi Maurizio,
>
> Does removing handling of clashes from TransTypes make 'hypothetical' 
> bridges unnecessary?
It is possible, I need to spend some more time looking into this patch 
from a compatibility perspective - e.g. make sure that under no 
circumstance the code I have removed would be triggered by some user 
code. This is tricky to verify, since TransTypes doesn't exactly assert 
the override clash rules defined in the JLS, so there might be more 
things caught in that net (I'm thinking esp. about separate compilation).

Thanks
Maurizio
>
> The comments in TransTypes say hypothetical bridges are used to detect 
> clashes, but if we're not doing that anymore perhaps that code can be 
> removed too? That would make JDK-8133247 obsolete.
>
> On Mon, May 21, 2018 at 10:30 AM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     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/
>     <http://cr.openjdk.java.net/%7Emcimadamore/8203488/>
>
>     Maurizio
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180522/b01c1d2d/attachment-0001.html>