RFR 8203488: Remove error generation from TransTypes

[Maurizio Cimadamore]

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/1b4f0a5e/attachment.html>