RFR 8203488: Remove error generation from TransTypes
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Tue May 22 22:42:39 UTC 2018
On 22/05/18 22:15, Vicente Romero wrote:
> can the HYPOTHETICAL flag be removed now?
Not really - IIRC, it is also used by poly sig method symbols that are
synthetically generated using the callsite type info.
I will double check though.
Maurizio
>
> On 05/22/2018 02:18 PM, Maurizio Cimadamore wrote:
>>
>> 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/65414ee4/attachment.html>
More information about the compiler-dev
mailing list