aboutsummaryrefslogtreecommitdiffstats
path: root/erts/etc
diff options
context:
space:
mode:
authorBjörn Gustavsson <[email protected]>2016-05-18 19:14:09 +0200
committerBjörn Gustavsson <[email protected]>2016-05-23 08:39:52 +0200
commit9ab0dcce5a2bf609917cb09c36cbf63dad6bb679 (patch)
tree0a92402f81e8bbf327987cf9462901adbab4e21a /erts/etc
parent121cc9ba61e44e9c47d831d837dfb0f0b2d81990 (diff)
downloadotp-9ab0dcce5a2bf609917cb09c36cbf63dad6bb679.tar.gz
otp-9ab0dcce5a2bf609917cb09c36cbf63dad6bb679.tar.bz2
otp-9ab0dcce5a2bf609917cb09c36cbf63dad6bb679.zip
v3_core: Don't depend on sys_core_fold for cleaning up
a3ec2644f5 attempted to teach v3_core not to generate code with unbound variables. The approach taken in that commit is to discard all expressions following a badmatch. That does not work if the badmatch is nested: {[V] = [] = foo,V}, V That would be rewritten to: {error({badmatch,foo})}, V where V is unbound. If we were to follow the same approach, the tuple construction code would have to look out for a badmatch. As would list construction, begin...end, and so on. Therefore, as it is impractical to discard all expressions that follow a badmatch, the only other solution is to ensure that the variables that the pattern binds will somehow be bound. That can be arranged by rewriting the pattern to a pattern that binds the same variables. Thus: error({badmatch,foo}), E = foo, case E of {[V],[]} -> V; Other -> error({badmatch,Other} end
Diffstat (limited to 'erts/etc')
0 files changed, 0 insertions, 0 deletions