-
Notifications
You must be signed in to change notification settings - Fork 531
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
Loosen Typeable
restriction
#900
Loosen Typeable
restriction
#900
Conversation
Fixes milessabin#812 Don't reject materializing a `Typeable` instance due to the presence of a non-case-accessor value, unless its type is abstract.
Codecov Report
@@ Coverage Diff @@
## master #900 +/- ##
======================================
Coverage 87.9% 87.9%
======================================
Files 65 65
Lines 1497 1497
Branches 5 5
======================================
Hits 1316 1316
Misses 181 181
Continue to review full report at Codecov.
|
Interestingly |
7f08f9b
to
66f403a
Compare
To clarify the issue, this check was added in #575: val nonCaseAccessor = tpe.decls.exists {
case sym: TermSymbol if !sym.isCaseAccessor && (sym.isVal || sym.isVar ||
(sym.isParamAccessor && !(sym.accessed.isTerm && sym.accessed.asTerm.isCaseAccessor))) => true
case _ => false
}
if (nonCaseAccessor) {
// there is a symbol, which is not a case accessor but a val,
// var or param, so we won't be able to type check it safely:
c.abort(c.enclosingPosition, s"No default Typeable for parametrized type $tpe")
} What this amounts to is rejecting any case class that defines a case class Foo(a: Int) {
val foo = 22
} This is a bit too strict (and leads to bug #812). Instead, there should also be a check as to whether the value's type is parametric. So this PR adds a check that this is the case. It's possible that this is still even too strict, as in here: case class Foo[A](a: A) {
val aa = a
} Here, the presence of |
Yup, this LGTM! You've won your t-shirt! |
* Loosen typeable restrictions Fixes milessabin#812 Don't reject materializing a `Typeable` instance due to the presence of a non-case-accessor value, unless its type is abstract. * Fix Scala 2.10 issue
Fixes #812
Don't reject materializing a
Typeable
instance due to the presence of a non-case-accessor value, unless its type is abstract. The abstract type is what makes it unsafe, so we should only reject if that's the case.