diff options
author | Björn Gustavsson <[email protected]> | 2010-09-22 11:09:57 +0200 |
---|---|---|
committer | Björn Gustavsson <[email protected]> | 2010-09-22 14:48:22 +0200 |
commit | 5daa0013177545446b26cdba0dbd167f0e040d63 (patch) | |
tree | 65a9ba5e7ea9291dc3202ef0830de261a64fb799 /erts | |
parent | 3142041ade649cfb783b4c1a52ee67cd2d2212f9 (diff) | |
download | otp-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