aboutsummaryrefslogtreecommitdiffstats
path: root/.gitattributes
diff options
context:
space:
mode:
authorBjörn Gustavsson <[email protected]>2015-01-16 15:06:53 +0100
committerBjörn Gustavsson <[email protected]>2015-01-26 13:08:48 +0100
commit1ef53ead19d5bd07caad4daa71b8fecf2fbcd2a6 (patch)
tree00d9dd67d47c8cd7fdf7cee71d8fb0141dad03be /.gitattributes
parenta1243173ed98d1006914337b94f28c9594bd8b02 (diff)
downloadotp-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 '.gitattributes')
0 files changed, 0 insertions, 0 deletions