<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hello José, hello Björn,<br class=""><br class="">We already have two warnings:<br class=""><br class="">- "this clause cannot match because a previous clause at line X always matches"<br class="">- "this clause cannot match because of different types/sizes"<div class=""><br class=""></div><div class="">The second is triggered for matches like "{_} = {X,Y}". Shouldn't we just use it in that case?</div><div class=""><br class="">Note that diagnostics would help in the clause shadowing case:</div><div class=""><br class=""></div><div class="">foo.erl:3:8: Warning: this clause cannot match because a previous clause at line 2 always matches</div><div class=""><span style="white-space:pre" class="Apple-tab-span"> </span>a -> bad</div><div class=""><span style="white-space:pre" class="Apple-tab-span"> </span>^~~~~~~~</div><div class="">foo:erl:2:8: Note: This clause shadows clause at line 3</div><div class=""><span style="white-space:pre" class="Apple-tab-span"> </span>Var -> good;</div><div class=""> ^~~~~~~~~~~</div><div class=""><br class=""></div><div class="">Or something like that.</div><div class=""><br class=""></div><div class="">Regards,<br class=""><br class=""><div class="">-- <br class=""><div>Anthony Ramine<br class=""></div><br class="">Le 17 juin 2013 à 11:08, Björn Gustavsson a écrit :<br class=""><br class=""><blockquote type="cite">On Sun, Jun 16, 2013 at 5:38 PM, José Valim <<a href="mailto:jose.valim@plataformatec.com.br">jose.valim@plataformatec.com.br</a>> wrote:</blockquote><div class=""><blockquote type="cite"><br></blockquote></div><blockquote type="cite"><blockquote type="cite">Hello,<br><br>I have found a bug on the "cannot match clause" warning. Consider this minimal case:<br><br>-module(foo).<br>-export([bar/0]).<br><br>bar() -><br> V = <<"hello">>,<br> case is_binary(V) of<br> false -> good;<br> true -> bad<br> end.<br><br>When compiled, the code above spews the following warning:<br><br>$ erlc foo.erl<br>foo.erl:7: Warning: this clause cannot match because a previous clause at line 8 always matches<br><br>In fact, the clause that always match is the following one and not the previous one. One simple fix for this issue is to change the message to:<br><br>foo.erl:7: Warning: this clause cannot match because another clause at line 8 always matches<br class=""></blockquote><br class="">This is tricky and I will have to think about how to best<br class="">fix the problem.<br class=""><br class="">I want to keep the current wording of the warning when it<br class="">is appropriate, for example for the following code:<br class=""><br class=""> case E of<br class=""> Var -> ...;<br class=""> a -> ...<br class=""> end.<br class=""><br class="">In this case, the use of a variable forces the order in<br class="">which the clauses are matched.<br class=""><br class="">In your example, a more appropriate message would be<br class="">something like: "this clause cannot match, because the case<br class="">expression evaluates to a literal, but it is the wrong literal".<br class="">I am not sure yet how to best produce that message.<br class=""><br class="">The reason that it is tricky is that the code is transformed<br class="">in several internal steps. After one of those steps, the<br class="">code would look something like this (if it were to be<br class="">translated back to Erlang source code from Core Erlang<br class="">code):<br class=""><br class=""> if<br class=""> is_binary(V) -> bad;<br class=""> true -> good<br class=""> end<br class=""><br class="">(That transformation is done because the compiler will<br class="">generally generate better code for guard expressons.)<br class=""><br class="">When that code is further optimized, it will be seen that<br class="">that the first clause will always match and a warning will<br class="">be generated for the second clause in the 'if'.<br class=""><br class="">It seems that I will have to add some sort of annotation<br class="">to the transformed code so that the appropriate warning<br class="">could be produced, or alternately evaluate the case<br class="">expression before attempting to to move it into the guard.<br class=""><br class="">/Bjorn<br class=""></blockquote><br class=""></div></div></body></html>