There is a cavalcade of interesting issues illuminated by this snippet.
Your code contains a type error – this change will make it correct: map.put(tmp,collection.mutable.Map()).
When the compiler encounters this error, it triggers an implicit search to convert `map` to a type with a suitable `put` method. Alarmingly, this search includes `JavaConversions.asJavaDictionary`, despite the absense of an import! Why, you may ask? Well, WeakHashMap extends JavaConversions.JMapWrapper, and the implicits of a nested type include those defined in its enclosing scopes (object or package object). This behaviour isn't specified, see: SI-4427. I suspect that this consequence of putting JMapWrapper in JavaConversions was unintended.
So, the compiler tries to use:
This line of code, when compiled verbatim fails as one expects. The compiler infers the type argument as:
and fails with:
error: polymorphic expression cannot be instantiated to expected type;
found : [A]scala.collection.mutable.Set[A]
But for implicit views, things proceed along a different path. The inferred type arguments are:
collection.this.JavaConversions.asJavaDictionary[AnyRef, <284574 characters of inferred type elided>]
No, really. I've attached said gargantuan-type.txt for posterity. Unsurprisingly, the second argument to put doesn't conform. That's when TypeDiagnostics takes over and brings down the compiler.
TypeDiagnostics has the admirable intention to add just enough qualification of identifiers in type errors to make them unambiguous, while still maintaining readability. Processes each pair of types referenced in the type error, and adding qualification to those with the same name that refer to distinct types. This cartesian product is not processed lazily, and it exhausts the heap.
It seems that this work is all for nought anyway – we just want to rule out ineligible implicit views, the carefully crafted message wouldn't make it to the user anyway.