Complexity reduction when choosing the best inference leaf to be solved
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Oct 4 16:04:54 UTC 2017
Ok, I'll add some extra assertions to the code and then check it more
closely.
There are situations in which type variables are cloned - and sometimes
you can have different clones of the same var in the same inference
context - e.g. in situation like these
g(m(), m())
That said, two type var clone should not be .equals, nor ==, so that
would not explain as to why multiple nodes containing the 'same'
inference vars were found in an inference graph.
Maurizio
On 04/10/17 16:03, B. Blaser wrote:
> On 4 October 2017 at 13:55, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>>
>> On 04/10/17 11:08, B. Blaser wrote:
>>> That's what I thought, too. But with a "Map<Type, Node>", I was
>>> surprised by a small set of failing tests because of more than one
>>> node per variable. Is there any problem elsewhere?
>> I think we need to look at those tests - do you have a pointer to what they
>> were?
> I don't remember exactly, but probably in "test/tools/javac/lambda".
> My first idea was to replace the node list with a "LinkedHashMap<Type,
> Node>" to have both benefits of an ordered list and a map. So, simply
> replacing the list by the map and re-running the tests should reveal
> the problem (I put an "Assert.check(map.remove(t) != null)" when
> removing a node which made some tests fail).
>
> Bernard
>
>
>> Thanks
>> Maurizio
More information about the compiler-dev
mailing list