JDK-8219318 (???): inferred type does not conform to upper bound(s) when collecting to a HashMap

[B. Blaser]

Thanks for this explanation, Maurizio.

I understand that your main concern is to make sure that javac
conforms to the JLS and it probably does but I still remain perplexed
about this inference inconsistency.

I've no problem with putting aside stuck arguments during overload
resolution but the notion of pertinence to applicability is really
misleading.
I had trouble understanding that 'toMap()' could be a potentially
applicable method if 'HashMap::new' isn't pertinent to applicability
in the sense of the JLS.
But, as you explained, this argument is left over during overload
resolution and reinstated after causing the inconsistency between
'putAll()' and 'broker='.

Which is still confusing to me is that javac gives another definition
of stuck arguments between overload resolution [1] and invocation type
inference [2] relating this to their pertinence to applicability.

The motivation of my fix was therefore to unify these definitions to
also consider arguments that aren't "really" stuck during overload
resolution which may conform to the JLS (or not?).

But as I don't see much enthusiasm in going in this direction, I'll
close this issue as you suggested.

Thanks,
Bernard

[1] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1255
[2] http://hg.openjdk.java.net/jdk/jdk/file/cec148db7b55/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1145

On Mon, 16 Dec 2019 at 22:06, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> [...]
> So, this is the JLS explanation as to why things work in one case, but
> not in the other.
>
> Maurizio