diff options
author | Jason Zaugg <jzaugg@gmail.com> | 2014-02-22 20:33:43 +0100 |
---|---|---|
committer | Jason Zaugg <jzaugg@gmail.com> | 2014-03-15 21:11:00 +0100 |
commit | b7f359c718717262fa447f428dbd600ddd3b29bd (patch) | |
tree | 0d0f31673cd8404a0b94c46b57eba974627d6243 /test/files/pos/lubs.scala | |
parent | 9c38e86a5526887f93a3f031b19a0e4fa31745d3 (diff) | |
download | scala-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/files/pos/lubs.scala')
0 files changed, 0 insertions, 0 deletions