aboutsummaryrefslogtreecommitdiffstats
path: root/AUTHORS
diff options
context:
space:
mode:
authorBjörn Gustavsson <[email protected]>2013-12-20 15:28:06 +0100
committerBjörn Gustavsson <[email protected]>2014-01-16 10:23:40 +0100
commite12b7d5331c58b41db06cadfa4af75b78b62a2b1 (patch)
tree8c771122ab933288a7a43c7531a31f1d620ed301 /AUTHORS
parentb2812193cfc8f0e98520984080a4cb87230b1f0b (diff)
downloadotp-e12b7d5331c58b41db06cadfa4af75b78b62a2b1.tar.gz
otp-e12b7d5331c58b41db06cadfa4af75b78b62a2b1.tar.bz2
otp-e12b7d5331c58b41db06cadfa4af75b78b62a2b1.zip
Generalize optimizations of case statements
Case expressions such as: case {Expr1,Expr} of {V1,V2} -> ... end are already optimized to not actually build the tuple. Generalize the optimization to avoid building any kind of composite term, such as: case {ok,[A,B]} of {ok,[X,Y]} -> ... end We don't expect programmers to write such code directly, but inlining can produce such code. We need to be careful about the warnings we produce. If the case expression is a literal, it is expected that no warnings should be produced for clauses that don't match. We must make sure that we continue to suppress those warnings.
Diffstat (limited to 'AUTHORS')
0 files changed, 0 insertions, 0 deletions