RFR 8203488: Remove error generation from TransTypes

[Maurizio Cimadamore]

Submitted new revision; changes:

* removed more code from TransTypes (HYPOTHETICAL and other stuff)

* added a new error when polysig metods are called with wrong -target 
(note, this will go away in 12, as the 6 target will be dropped, so I 
don't think we need to spend too many cycles on this)

Webrev:

http://cr.openjdk.java.net/~mcimadamore/8203488-v2/

Cheers

Maurizio


On 21/05/18 18:30, Maurizio Cimadamore 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/
>
> Maurizio
>
>
>
>

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