RFR 8178150: Regression in logic for handling inference stuck constraints

[Vicente Romero]

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/6c856aed/attachment.html>