RFR 8203488: Remove error generation from TransTypes

[Maurizio Cimadamore]

On 21/05/18 18:51, Remi Forax wrote:
>
>
> ------------------------------------------------------------------------
>
>     *De: *"Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
>     *À: *"compiler-dev" <compiler-dev at openjdk.java.net>
>     *Envoyé: *Lundi 21 Mai 2018 19:30:01
>     *Objet: *RFR 8203488: Remove error generation from TransTypes
>
>     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.
>
>
> With my JSR 292 hat, Polymorphic signature calls should have not been 
> allowed in 6 (-source 6), calling it as a varargs is never was you 
> want, this feature should only be enabled for 7+
> I'm not a big fan of generating a code that will not work at runtime, 
> i think it's better to explain to the user that he/she should use 
> --release 7.
> So instead of trying to revert to a basic call, i think it's better to 
> just emit an error early in Attr.
That's an option too, either error or warning.


>
>     Of course, same code would fail to compile if using --release 6
>     (as MethodHandle API was not there in 6).
>
>
> BTW, the VarHandle API also add more calls tagged with 
> @PolymorphicSignature and the semantics of a polymorphic siganture 
> calls was sightly changed, i wonder how the compiler behave when you 
> calls one of these methods with -source 7 or 8 ?
Good point; seems like whatever we do for MH in -target 6, we should do 
for VH in target < 9.

Maurizio
>
>     Webrev:
>
>     http://cr.openjdk.java.net/~mcimadamore/8203488/
>
>     Maurizio
>
>
> Rémi
>

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