diff options
author | Björn Gustavsson <[email protected]> | 2015-01-16 15:06:53 +0100 |
---|---|---|
committer | Björn Gustavsson <[email protected]> | 2015-01-26 13:08:48 +0100 |
commit | 1ef53ead19d5bd07caad4daa71b8fecf2fbcd2a6 (patch) | |
tree | 00d9dd67d47c8cd7fdf7cee71d8fb0141dad03be /erts/info.src | |
parent | a1243173ed98d1006914337b94f28c9594bd8b02 (diff) | |
download | otp-1ef53ead19d5bd07caad4daa71b8fecf2fbcd2a6.tar.gz otp-1ef53ead19d5bd07caad4daa71b8fecf2fbcd2a6.tar.bz2 otp-1ef53ead19d5bd07caad4daa71b8fecf2fbcd2a6.zip |
sys_core_fold: Strengthen optimization of letrecs in effect context
We used to evaluate the body of a 'letrec' in value context, even
if the 'letrec' was being evaluated in effect context. In most
cases, the context does not matter because the body is usually
just an 'apply' which will never be optimized away.
However, in the case of incorrect code described in the previous
commit, it does matter. We can find such bad code by evaluating
the body in effect context. For example, if we have the following
incorrect code:
letrec
f/1 = fun(A) -> ... <use of Var> ...
in let Var = <<2:301>>
in apply(Arg)
If the letrec is evaluated in effect context, the code will be
reduced to:
letrec
f/1 = fun(A) -> ... <use of Var> ...
in seq Var = <<2:301>> do apply(Arg)
Now Var will be unbound and a later compiler pass will crash to
ensure that the bad Core Erlang code is noticed.
Also add a test case to ensure that the compiler crashes if the
bug fixed in the previous commit re-surfaces.
Diffstat (limited to 'erts/info.src')
0 files changed, 0 insertions, 0 deletions