RFR 8178150: Regression in logic for handling inference stuck constraints

[Maurizio Cimadamore]

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?

Maurizio


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/4bbf9e0a/attachment.html>