[cfe-dev] clang-format and BSD KNF

Richard Smith richard at metafoo.co.uk
Wed Jun 11 14:07:35 PDT 2014


On Wed, Jun 11, 2014 at 11:25 AM, Daniel Dilts <diltsman at outlook.com> wrote:

> > For example:
> >
> > int foo(int i);
> >
> > int
> > foo(int i)
> > {
> > …
> > }
> >
> > I’m having trouble distinguishing between function prototypes and
> definitions.
>
>
>
> 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.
>
> 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..
>
>
> 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.
>

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.

This rule seems pretty easy for clang-format to get right in the vast
majority of cases.

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.
>
> class C{};
> C c;
> int func1(C);
> C func2(c);
>
> 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.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140611/5c65e8ac/attachment.html>


More information about the cfe-dev mailing list