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

[Maurizio Cimadamore]

On 17/12/2019 12:32, B. Blaser wrote:
> 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.
Yes, the inconsistency is bad - but it seems like a specification issue, 
not a javac issue. That's what I'm trying to say (and why I was 
proposing to close the bug). Perhaps instead of closing we can move to 
the specification category, and attach my explanation?
>
> 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.
That's because during overload resolution, argument non-pertinent are 
simply stuck and should never ever be touched. But during invocation 
type inference, even arguments non-pertinent can be made available for 
further type-checking (depending on whether their 'input' set of stuck 
variables have been solved or not). The compiler implementation here is 
using the 'stuck' argument notion to model both 
pertinent-to-applicability _and_ dealing with the selection of argument 
in section 18.5.2.2.
>
> 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?).

That was the behavior we had for some time before Java 8 was finalized, 
where two symmetric processes were indeed happening, and 'unsticking' 
was also allowed to happen during overload; this led to issues, such as 
overload resolution being sensitive to errors triggered in the body of 
an unstuck lambda - which is why we moved to a saner (but asymmetric) model.


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

As I said above, I think the fact that we have a discrepancy between 
assignment context and invocation context, and one that is probably 
caused by incorporation rules not being strong enough when the overload 
target contains wildcards, is something that can be submitted for 
evaluation to the spec team. While we're not willing to make the 
overload and invocation inference process fully symmetric (for the 
reasons above), adding extra incorporation rules to help in cases like 
these doesn't seem (too) bad.

Maurizio

>
> 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