summaryrefslogtreecommitdiff
path: root/test/debug/OBSOLETE
diff options
context:
space:
mode:
authorJason Zaugg <jzaugg@gmail.com>2014-02-22 20:33:43 +0100
committerJason Zaugg <jzaugg@gmail.com>2014-03-15 21:11:00 +0100
commitb7f359c718717262fa447f428dbd600ddd3b29bd (patch)
tree0d0f31673cd8404a0b94c46b57eba974627d6243 /test/debug/OBSOLETE
parent9c38e86a5526887f93a3f031b19a0e4fa31745d3 (diff)
downloadscala-b7f359c718717262fa447f428dbd600ddd3b29bd.tar.gz
scala-b7f359c718717262fa447f428dbd600ddd3b29bd.tar.bz2
scala-b7f359c718717262fa447f428dbd600ddd3b29bd.zip
SI-8329 Better hygiene for patmat partial functions
Don't enter synthetic parameters of `applyOrElse` et al into scope when typechecking the user-code; instead reference those symbolically. There is an exception to this principle. Currently we allow: val x: PartialFunction[A, B] = x => x match { ... } For this pattern of code, we use the given name `x` for the corresponding method parameter of `applyOrElse` and `isDefinedAt` and we actually need this to be in scope when we typecheck the scrutinee. This construct is tested in `run/virtpatmat_partial.scala`. A new parameter, `paramSynthetic`, differentiates this case from the more typical `val x: PF[A, B] = { case ... => ... ; ... } case, which uses a fresh name need not be in scope. (We could get away with it, as it is fresh, but I thought it better to exclude it.)
Diffstat (limited to 'test/debug/OBSOLETE')
0 files changed, 0 insertions, 0 deletions