[cfe-dev] AST representation for parentheses inside types.

[Chandler Carruth]

On Fri, Dec 10, 2010 at 7:18 AM, Douglas Gregor <dgregor at apple.com> wrote:

>
> On Dec 10, 2010, at 12:18 AM, Enea Zaffanella wrote:
>
> > Il 09/12/2010 16:08, Douglas Gregor ha scritto:
> >>
> >> On Dec 8, 2010, at 12:02 PM, Enea Zaffanella wrote:
> >>
> >>> Il 07/12/2010 18:36, Douglas Gregor ha scritto:
> >>>>
> >>>> On Dec 7, 2010, at 6:39 AM, Enea Zaffanella wrote:
> >>>>
> >>>>> Hello.
> >>>>>
> >>>>> We noticed some time ago that the AST representation used in clang
> does
> >>>>> not allow for the representation of those pairs of parentheses that
> can
> >>>>> occur inside a syntactic type. For instance, the following C code:
> >>>>>
> >>>>> void ((((*fun_ptr))))(void);
> >>>>> int (*(int_arr_ptr))[15];
> >>>>> void (((*((*fun_ptr_arr_ptr)[10]))))(int, int);
> >>>>> int ((a));
> >>>>>
> >>>>> is printed (using -ast-print) as follows
> >>>>>
> >>>>> void (*fun_ptr)(void);
> >>>>> int (*int_arr_ptr)[15];
> >>>>> void (*(*fun_ptr_arr_ptr)[10])(int, int);
> >>>>> int a;
> >>>>>
> >>>>> The printed parentheses are not directly represented in the AST: they
> >>>>> are inserted by the pretty printer (to respect precedence).
> >>>>>
> >>>>> Are there plans to extend the AST in order to faithfully represent
> the
> >>>>> code above?
> >>>>
> >>>> Not that I know of.
> >>>>
> >>>>> To our eyes, it seems that the Type hierarchy should be enriched by
> >>>>> adding a ParenType derived class (similar to the ParenExpr class for
> the
> >>>>> Expr hierarchy). A ParenType would always be a non-canonical type and
> >>>>> the corresponding ParenTypeLoc would provide locations for the two
> >>>>> parentheses. At the parser level, we would have another kind of
> >>>>> DeclaratorChunk.
> >>>>>
> >>>>> Would this approach make sense?
> >>>>
> >>>> Yes, this approach makes sense to me.
> >>>>
> >>>>    - Doug
> >>>
> >>> OK, here is attached a patch along the sketch mentioned above.
> >>> It passes all clang tests but a single one.
> >>
> >> Looks great, with one comment below about the failing test.
> >>
> >>> The failing test is something related to ObjC, on which I have very
> >>> little confidence. Apparently, it seems that we should adjust the
> >>> expected output, which currently is as follows:
> >>>
> >>> FunctionDecl:{ResultType void}{TypedText f}{LeftParen (}{Placeholder
> >>> ^int(int x, int y)block}{RightParen )} (50)
> >>>
> >>> whereas we now obtain an extra pair of parentheses:
> >>>
> >>> FunctionDecl:{ResultType void}{TypedText f}{LeftParen (}{Placeholder
> int
> >>> (^)(int, int)}{RightParen )} (50)
> >>
> >> This probably just means that we need to look through ParenTypeLocs
> within the FormatFunctionParameter routine in SemaCodeComplete.cpp.
> >
> > Right, we were missing that source file.
> > Now even that one test passes.
>
> Great!
>
> >>> We look forward for suggestions/corrections/etc.
> >>
> >> How many parenthesized types do you see in a typical .c or .cpp file?
> >>
> >>      - Doug
> >
> > Well, of course the answer will depend on the meaning of "typical", but
> > anyway my guess is that they should be very few. Is it just curiosity or
> > are you really worried about the memory space impact?
>
>
> Just curious; you can go ahead and commit this. Parenthesized types aren't
> common enough to worry about.
>

Hah! So you say. I'll see you that overconfidence and raise you a testcase
from Boost's boost/math/special_functions/fpclassify.hpp:

% cat t.cc
template <typename T> inline bool (f)(T x) {
  return false;
}

template <typename T> inline T g(const T& v) {
  if (!(::f)(v))
    return 0;
  return v;
}

void test() {
  int i;
  g(i);
}

Crashes after this patch. I'm looking into it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20101213/f3c07492/attachment.html>