diff options
author | Björn Gustavsson <[email protected]> | 2013-12-20 15:28:06 +0100 |
---|---|---|
committer | Björn Gustavsson <[email protected]> | 2014-01-16 10:23:40 +0100 |
commit | e12b7d5331c58b41db06cadfa4af75b78b62a2b1 (patch) | |
tree | 8c771122ab933288a7a43c7531a31f1d620ed301 /AUTHORS | |
parent | b2812193cfc8f0e98520984080a4cb87230b1f0b (diff) | |
download | otp-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