RFR 8203488: Remove error generation from TransTypes
Vicente Romero
vicente.romero at oracle.com
Wed May 23 12:19:31 UTC 2018
looks good to me,
Vicente
On 05/23/2018 07:29 AM, Maurizio Cimadamore wrote:
>
> Here's another revision which adds the test for 8203488
>
> http://cr.openjdk.java.net/~mcimadamore/8203488-v3/
>
> The HYPOTHETICAL flag is not unused, but I think we could be able to
> drop it with a followup patch. But let's separate the efforts.
>
> Maurizio
>
>
> On 22/05/18 23:42, Maurizio Cimadamore wrote:
>>
>>
>>
>> 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/20180523/79f6c07e/attachment.html>
More information about the compiler-dev
mailing list