<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 11, 2014 at 11:25 AM, Daniel Dilts <span dir="ltr"><<a href="mailto:diltsman@outlook.com" target="_blank">diltsman@outlook.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><div dir="ltr"><div class="">> For example:<br>> <br>>   int foo(int i);<br>> <br>>   int<br>>   foo(int i)<br>>   {<br>>     …<br>>   }<br>> <br>> I’m having trouble distinguishing between function prototypes and definitions.<br>

 <br><br><br></div><div><div dir="ltr"><div><div dir="ltr"><div><div><div class=""><blockquote style="padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div><div dir="ltr">
I doubt that it is possible to distinguish between these cases.  clang-format works on a stream of tokens, not the AST.  I do not believe that there is any reliable way to distinguish between function prototypes and definitions without at least a partial AST.</div>
<div dir="ltr"> </div><div dir="ltr">Why not? One ends in a semicolon, the other in an open curly brace. clang-format has to make basically all of its decisions this way..</div></div></blockquote><div> </div></div><div>In the general case this would require infinite lookahead.  A function can have n parameters, each with a set of attributes.  I don't know if lookahead is supported in clang-format, so I won't comment on that.</div>
</div></div></div></div></div></div></div></div></blockquote><div><br></div><div>The nice thing about clang-format is that it doesn't need to get every obscure corner case right, and in practice it doesn't do so (there are parts of the C++ grammar where this isn't possible). But again, in practice, code where it's not "obvious" which grammar production is being used from local context is extremely rare, probably because it's hard for humans to reason about.</div>
<div><br></div><div>This rule seems pretty easy for clang-format to get right in the vast majority of cases.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div><div>The one case that I don't think is possible to do without some AST based information is to disambiguate variations of the most vexing parse.</div>
<div> </div><div>class C{};</div><div>C c;</div><div>int func1(C);</div><div>C func2(c);</div><div> </div><div>Without knowing that C is a type and c is a variable you cannot decide that func1 is a function declaration and func2 is a variable definition.</div>
</div></div></div></div>                                          </div></div>                                        </div></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>