<div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div>In some cases cover transforms binary comprehensions into non-working ones. Please consider example below:</div><div>---cut---</div><div></div></div></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><div>-module(wrong_transform).</div><div>-compile(export_all).</div><div><br></div><div>good() -></div><div>    << <<$,, X/binary>> || X <- [ <<"a">>, <<"b">> ]>>.</div><div><br></div><div>bad() -></div></div></div></div></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><div>    << <<",", X/binary>> || X <- [ <<"a">>, <<"b">> ]>>.<br>---cut---<br><br>With disabled cover, outputs of this functions are equal, `bad() =:= good()`. But if you do `cover:compile_beam/1` (see decompile.erl) it blows with `badarg` in `bad/0` function. Meanwhile `good/0` works well.<br><br></div></div></div></div></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><div>I've patched a bit `cover.erl` to dump AST forms before and after `cover:compile_beam/1` and found that for some reason it surrounds terms inside of comprehension with `begin ... end` pattern. It is wrong in case of list (I can't explain why, but it throws badarg, so I guess it is definitely an issue :)<br></div></div></div></div></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><br></div><div>Also I will appreciate if someone explain me why we do need this cover's trick with `begin .. end`.</div><div><br></div><div>Thank you!</div></div></div></div></div>