RFR 8178150: Regression in logic for handling inference stuck constraints

[Maurizio Cimadamore]

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/20171025/12021541/attachment.html>