RFR 8203488: Remove error generation from TransTypes

[Remi Forax]

> 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- [ https://bugs.openjdk.java.net/browse/JDK-8013179 | 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. 

> 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 ? 

> Webrev:

> [ http://cr.openjdk.java.net/~mcimadamore/8203488/ |
> 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/df6c6208/attachment.html>