diff options
author | Björn Gustavsson <[email protected]> | 2016-05-18 19:14:09 +0200 |
---|---|---|
committer | Björn Gustavsson <[email protected]> | 2016-05-23 08:39:52 +0200 |
commit | 9ab0dcce5a2bf609917cb09c36cbf63dad6bb679 (patch) | |
tree | 0a92402f81e8bbf327987cf9462901adbab4e21a /erts/etc | |
parent | 121cc9ba61e44e9c47d831d837dfb0f0b2d81990 (diff) | |
download | otp-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