RFR 8203488: Remove error generation from TransTypes (original) (raw)

Remi Forax forax at univ-mlv.fr
Mon May 21 17:51:37 UTC 2018

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>

More information about the compiler-dev mailing list