summaryrefslogtreecommitdiff
path: root/src/compiler/scala/tools/nsc/typechecker/Namers.scala
diff options
context:
space:
mode:
authorJason Zaugg <jzaugg@gmail.com>2014-10-29 13:19:33 +1000
committerJason Zaugg <jzaugg@gmail.com>2014-10-29 13:19:33 +1000
commit134d97dbf56fe96f0a820c78780dd92e8bf9c5e2 (patch)
tree379e4223ac70ec946d8e2ef57fc8645a71b06838 /src/compiler/scala/tools/nsc/typechecker/Namers.scala
parentbdae51d6a8f18a5456a32c350cb551d42a3cb6c6 (diff)
downloadscala-134d97dbf56fe96f0a820c78780dd92e8bf9c5e2.tar.gz
scala-134d97dbf56fe96f0a820c78780dd92e8bf9c5e2.tar.bz2
scala-134d97dbf56fe96f0a820c78780dd92e8bf9c5e2.zip
SI-8943 Handle non-public case fields in pres. compiler
When a case class is type checked, synthetic methods are added, such as the `hashCode`/`equals`, implementations of the `Product` interface. At the same time, a case accessor method is added for each non-public constructor parameter. This the accessor for a parameter named `x` is named `x$n`, where `n` is a fresh suffix. This is all done to retain universal pattern-matchability of case classes, irrespective of access. What is the point of allowing non-public parameters if pattern matching can subvert access? I believe it is to enables private setters: ``` case class C(private var x: String) scala> val x = new C("") x: C = C() scala> val c = new C("") c: C = C() scala> val C(x) = c x: String = "" scala> c.x <console>:11: error: variable x in class C cannot be accessed in C c.x ^ scala> c.x = "" <console>:13: error: variable x in class C cannot be accessed in C val $ires2 = c.x ^ <console>:10: error: variable x in class C cannot be accessed in C c.x = "" ^ ``` Perhaps I'm missing additional motivations. If you think scheme sounds like a binary compatiblity nightmare, you're right: https://issues.scala-lang.org/browse/SI-8944 `caseFieldAccessors` uses the naming convention to find the right accessor; this in turn is used in pattern match translation. The accessors are also needed in the synthetic `unapply` method in the companion object. Here, we must tread lightly to avoid triggering a typechecking cycles before; the synthesis of that method is not allowed to force the info of the case class. Instead, it uses a back channel, `renamedCaseAccessors` to see which parameters have corresonding accessors. This is pretty flaky: if the companion object is typechecked before the case class, it uses the private param accessor directly, which it happends to have access to, and which duly gets an expanded name to allow JVM level access. If the companion appears afterwards, it uses the case accessor method. In the presentation compiler, it is possible to typecheck a source file more than once, in which case we can redefine a case class. This uses the same `Symbol` with a new type completer. Synthetics must be re-added to its type. The reported bug occurs when, during the second typecheck, an entry in `renamedCaseAccessors` directs the unapply method to use `x$1` before it has been added to the type of the case class symbol. This commit clears corresponding entries from that map when we detect that we are redefining a class symbol. Case accessors are in need of a larger scale refactoring. But I'm leaving that for SI-8944.
Diffstat (limited to 'src/compiler/scala/tools/nsc/typechecker/Namers.scala')
-rw-r--r--src/compiler/scala/tools/nsc/typechecker/Namers.scala1
1 files changed, 1 insertions, 0 deletions
diff --git a/src/compiler/scala/tools/nsc/typechecker/Namers.scala b/src/compiler/scala/tools/nsc/typechecker/Namers.scala
index e876d4a6af..95d4711c5f 100644
--- a/src/compiler/scala/tools/nsc/typechecker/Namers.scala
+++ b/src/compiler/scala/tools/nsc/typechecker/Namers.scala
@@ -413,6 +413,7 @@ trait Namers extends MethodSynthesis {
if (isRedefinition) {
updatePosFlags(existing, tree.pos, tree.mods.flags)
setPrivateWithin(tree, existing)
+ clearRenamedCaseAccessors(existing)
existing
}
else assignAndEnterSymbol(tree) setFlag inConstructorFlag