Complexity reduction when choosing the best inference leaf to be solved

[Maurizio Cimadamore]

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