RFR 8203488: Remove error generation from TransTypes

[forax at univ-mlv.fr]

> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "compiler-dev" <compiler-dev at openjdk.java.net>, "John Rose"
> <john.r.rose at oracle.com>
> Envoyé: Lundi 21 Mai 2018 22:09:11
> Objet: Re: RFR 8203488: Remove error generation from TransTypes

> On 21/05/18 18:51, Remi Forax wrote:

>>> De: "Maurizio Cimadamore" [ mailto:maurizio.cimadamore at oracle.com |
>>> <maurizio.cimadamore at oracle.com> ]
>>> À: "compiler-dev" [ mailto:compiler-dev at openjdk.java.net |
>>> <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.

> That's an option too, either error or warning.
I think an error is better here, like when you try to use a feature with a JDK least recent that the one that introduce the feature. 

Rémi 

>>> 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/%7Emcimadamore/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/960859ae/attachment-0001.html>