Fix #1907: Improve error message #1921
Conversation
The previous condition for caching companionRefs contained a condition
result.companionRefs.forall(implicitScopeCache.contains)
which was always false because we cache types in `implicitCodeCache`, not
companion refs. The new logic fixes this and does not need a second traversal
because it is integrated in `iscopeRefs`.
When printing info about adding to constraints, show the hashes of the typerstate stack, so that we know where constraints are added.
The test exercises all the improvements made in previous commits of this branch.
The previous implicit definition of arrayTag in DottyPredef priorities arrayTag over all other classtag searches, which led to surprising results in `i1907a.scala`.
It seems in most cases this leads to weird behavior and cause confusing error messages later. It also means we cannot create an Array[Nothing], except by passing the classtag explicitly.
|
I'll need to page this back in to comment meaningfully, but for now, I'll dump some links to related discussions about soundness issues with arrays and/or class tags of bottom types: https://issues.scala-lang.org/browse/SI-9754 |
Updated with SI issues reported by Jason
|
@retronym Thanks for the links. They are all treated OK under this commit. I am not sure whether they would have been soundness issues before, since dotc with its union types behaves differently than scalac. So for instance i1907.scala is compiled by scalac but rejected by dotc. |
|
This also indirectly solves #1730, I think it's fine to require the user to be explicit when dealing with |
|
Yes, you're right, otherwise the soudness hole is still there. |
Two fixes:
ClassTag[Nothing]orClassTag[Null].The second point is likely contentious. It does forbid some programs that would make sense such as
But it also avoids many situations that would lead to surprising results or confusing errors later.
@retronym What is your take on this?