-
Notifications
You must be signed in to change notification settings - Fork 3.1k
When testing for presence of a Symbol in a Type don't skip aliases. #6122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Relevant prior commit: a56afcd. Nb. I based the unit test on |
|
See also scala/scala-dev#207 |
|
Thanks for the pointer ... I'll run a community build when this goes green. |
|
The community build fails with scalaz: the change produces some new implicit ambiguities ... similar situation to the SI-2712 fix. |
|
I'm going to review this shortly by:
|
|
I've added a neg test which illustrates the sort of revealed ambiguity failures we get with this fix in place. class Foo[F[_]]
object Foo {
// Prior to this fix these two are ambiguous
implicit def fooF0[F[_]]: Foo[F] = new Foo[F]
implicit def fooF1: Foo[Option] = new Foo[Option]
}
class Bar[F[_]]
object Bar extends Bar0 {
// Prior to this fix these two aren't selected because there is no
// Foo[F] due to the ambiguity above
// After this fix these two are ambiguous
implicit def barF0[F[_]](implicit fooF: Foo[F]): Bar[F] = new Bar[F]
implicit def barF1[F[_]](implicit fooF: Foo[F]): Bar[F] = new Bar[F]
}
trait Bar0 {
// Prior to this fix we fall back to here
implicit def barF2[F[_]]: Bar[F] = new Bar[F]
}
object Test {
// Prior to this fix Bar.barF2[Option]
// After this fix,
// error: ambiguous implicit values:
// both method barF0 in object Bar of type [F[_]](implicit fooF: Foo[F])Bar[F]
// and method barF1 in object Bar of type [F[_]](implicit fooF: Foo[F])Bar[F]
// match expected type Bar[Option]
// implicitly[Bar[Option]]
// ^
// one error found
implicitly[Bar[Option]]
} |
|
@adriaanm I'd be happy to target this at 2.13.x too. |
f824db2 to
add5a1e
Compare
|
Rebased to 2.13.x ... |
add5a1e to
16ad098
Compare
The implementation of
ContainsCollectoroverly aggressively normalizes away aliases resulting in symbols corresponding to higher-kinded type variables being missed. This shows up inexistentialAbstractionwhere a type like[F[_]]C[F]which should be taken toC[F] forSome { type F[_] }is instead taken toC[F](whereFhas escaped its quantifier). This is responsible for errors of the form reported in scala/bug#10545 because implicit selection is driven by a specificity test which in turn relies onexistentialAbstraction.I've made the smallest possible change that fixes this problem, however I think that
ContainsCollectoris ambivalent about its use ofnormalizeand should probably be reworked to either fully normalize (in which caseType#containswill see through all aliases) or to not normalize at all apart from the case where it's required to handle refined types correctly.Fixes scala/bug#10545. All (par)tests pass.