inference trouble with recursive generics and raw types

[Dan Smith]

I'm not an expert on exactly what javac does internally to implement bounds checking and incorporation during inference.  Which is really what you need, if you're trying to prove that you've got identical behavior.

I think how I would try to approach it is to treat declared upper bounds as "soft" bounds (via some sort of flag).  The when comparing this upper bound to a lower or eq bound, I would allow for unchecked conversion.  That strategy would allow your example at the start of the thread to compile, and seems to be close to what javac is doing, which is (again, as best I can tell) to allow unchecked conversion during checking of declared bounds.

—Dan

On Dec 1, 2013, at 8:22 AM, Stephan Herrmann <stephan.herrmann at berlin.de> wrote:

> I made some experiments, because this is currently the most
> relevant open question regarding our inference implementation.
> 
> We now have a flag to toggle the following two changes:
> (1): In 18.2.3 I made an addition similar to the new (as of 0.7.0)
>     18.2.2 bullet 4
> (2): If Invocation Type Inference fails, I go back to the results
>     from Applicability Inference and if that produces a return type
>     whose erasure is compatible with the target type I proceed
>     with this solution and an unchecked warning.
> 
> Results:
> When expecting results similar to javac:
> (1) fixes 17 regressions in the current test suite (of 1494 tests)
> (2) fixes 6 regressions in that suite
> Both changes together cause 6 new regressions.
> 
> It seems my changes go in the right direction, but use the wrong
> size of a drill. I'm running out of ideas how to let ECJ approximate
> the buggy javac behavior in the 1.8 era. I could really use some help
> in capturing the exact extent of that bug.
> 
> Let me know if you'd like to see specimen of the regressions in
> different directions, mentioned above.
> 
> thanks,
> Stephan
> 
> 
> On 11/27/2013 08:14 PM, Stephan Herrmann wrote:
>> Hi Dan,
>> 
>> Thanks for letting us know.
>> 
>> Given we (Eclipse) now have an implementation of type inference
>> that is very close to the new spec, and thus *doesn't* exhibit the bug,
>> do you have any hints on how we should add this bug on top of this
>> new implementation?
>> What exactly is the extent of the bug? In which situations does javac
>> check for convertibility where it actually should check for subtyping?
>> 
>> Ideally, I could use an inofficial addendum to the inference spec,
>> that makes the spec conform to javac, so we have a realistic chance
>> to make ecj conform to both.
>> 
>> best,
>> Stephan
>> 
>> ----- ursprüngliche Nachricht ---------
>> 
>> Subject: Re: inference trouble with recursive generics and raw types
>> Date: Mi 27 Nov 2013 01:39:03 CET
>> From: Dan Smith<daniel.smith at oracle.com>
>> To: Stephan Herrmann&lt;stephan.herrmann at berlin.de&gt;
>> 
>> On Nov 5, 2013, at 11:03 AM, Dan Smith <daniel.smith at oracle.com> wrote:
>> 
>>> I'll have some conversations internally about how we feel about the unchecked conversion bug
>> 
>> Following up.
>> 
>> Here's the javac bug:
>> https://bugs.openjdk.java.net/browse/JDK-8026527
>> 
>> There's a consensus that this is far too risky to cram late into 8, and a sense that this is probably something we will change in 9.  (This sort of change in the set of accepted programs is not something we generally allow in update releases.)
>> 
>> —Dan
>> 
>> ---- ursprüngliche Nachricht Ende ----
>> 
>