RFR 8178150: Regression in logic for handling inference stuck constraints

[Vicente Romero]

looks good,
Vicente

On 06/13/2018 12:01 PM, Maurizio Cimadamore wrote:
>
> Here's a finalized webrev; I've incorporated few comments from this 
> discussion:
>
> * have predictable inference var resolution (B. Blaser)
> * change stream back to for each (A. Golovnin)
>
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/8178150_v3/
>
> Cheers
> Maurizio
>
>
>
> On 13/06/18 13:43, Vicente Romero wrote:
>>
>>
>> On 06/13/2018 04:05 AM, Maurizio Cimadamore wrote:
>>>
>>> Resurrecting this old thread.
>>>
>>> There haven't been many comments on the spec side of this.
>>>
>>> I'm tempted to go ahead and submit (after proper re-testing)  one 
>>> last iteration of this patch. The focus would be on fixing the 
>>> regression in stuck constraint resolution that has been affecting 
>>> the compiler for a while - I plan to leave performance and 
>>> spec-related issues as part of follow up tasks - I don't think we 
>>> came across on evidence that this patch regresses on either fronts.
>>>
>>> Thoughts?
>>>
>>
>> go for it :)
>>
>>> Maurizio
>>>
>>
>> Vicente
>>
>>>
>>> On 25/10/17 01:33, Maurizio Cimadamore wrote:
>>>>
>>>>
>>>>
>>>> On 25/10/17 00:43, Maurizio Cimadamore wrote:
>>>>> lead to the same set of input variables; there is actually a very 
>>>>> tiny difference, in that the latter constraint doesn't add in the 
>>>>> input variable set the input variables of the constraints coming 
>>>>> from the return expressions of the lambda - and that's because, I 
>>>>> think, you can reason about exceptions being thrown by a lambda 
>>>>> even if some return expressions are 'stuck'. Which means I guess, 
>>>>> at least hypothetically, you could write a test where the spec 
>>>>> picks ‹/LambdaExpression/ →_/throws/ T› and decides to process 
>>>>> that ahead of  ‹/LambdaExpression/ → T› - while in javac the two 
>>>>> happen at the same time (because javac doesn't have the 
>>>>> distinction between these two constraints - throws constraints are 
>>>>> evaluated as part of evaluating the lambda compatibility constraint).
>>>> Actually, it's slightly different - that is:
>>>>
>>>> ‹/LambdaExpression/ →_/throws/ T›
>>>>
>>>> has a _broader_ set of input variables than
>>>>
>>>>  ‹/LambdaExpression/ → T›
>>>>
>>>> As the former includes as input variables all variables mentioned 
>>>> in the return type of the function type derived from T.
>>>>
>>>> This reduces the mismatch even further - basically what the spec is 
>>>> saying is that you don't want to process checked exception 
>>>> constraints in cases where the target contains free variables, 
>>>> because such variables might affect the set of thrown types by the 
>>>> lambda.
>>>>
>>>> That said, I will have to think more about specific cases where the 
>>>> spec would consider ‹/LambdaExpression/ →_// T› ahead of the 
>>>> companion constraint ‹/LambdaExpression/ →_// throws T›, and see 
>>>> what's the impact in terms of real code. From the looks of it this 
>>>> looks like (i) something that was there even before the regression 
>>>> that this patch is attempting to fix and (ii) probably more in the 
>>>> corner case territory; while non conformance issues should be 
>>>> treated for what they are, I think there's enough of a case here to 
>>>> investigate this as part of a followup issue?
>>>>
>>>> Maurizio
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180613/1164aad7/attachment.html>