aboutsummaryrefslogtreecommitdiffstats
path: root/erts
diff options
context:
space:
mode:
authorBjörn Gustavsson <[email protected]>2010-09-22 11:09:57 +0200
committerBjörn Gustavsson <[email protected]>2010-09-22 14:48:22 +0200
commit5daa0013177545446b26cdba0dbd167f0e040d63 (patch)
tree65a9ba5e7ea9291dc3202ef0830de261a64fb799 /erts
parent3142041ade649cfb783b4c1a52ee67cd2d2212f9 (diff)
downloadotp-5daa0013177545446b26cdba0dbd167f0e040d63.tar.gz
otp-5daa0013177545446b26cdba0dbd167f0e040d63.tar.bz2
otp-5daa0013177545446b26cdba0dbd167f0e040d63.zip
Don't generate multiple tail segments in binary matching
In binary matching, there must only be one "tail segment" (i.e. a size-less segment of type binary) and it must be last. Thus, the compiler will reject the following function definition: foo(<<A/bits,B/bits>>) -> ok. But code such as the following: [42 || <<_:8/integer, _/bits>> <= Bits] will internally (in the Core Erlang format) be translated to a binary matching pattern containing two tail segments. The compiler happens to generate correct code anyway (later passes will get rid of the redundant tail segment), but it is ugly and will confuse tools such as Dialyzer. Change the transformation of binary generators (in both list and binary comprehensions) not to generate add a tail segment if there already is one.
Diffstat (limited to 'erts')
0 files changed, 0 insertions, 0 deletions