FunctionDecls by typedef crash the C++ front-end

e.g:

typedef void fn(int);
fn f;

There are no ParmVarDecls created for the 'f' FunctionDecl, and I assume this is intended to save space.
This crashes the C++ front-end when trying to use the ParmVarDecls (mostly for handling default args).

In C there is no problem since ParmVarDecls are used only for definitions, otherwise FunctionTypeProto is used

-Argiris

Two options here. The best is probably for the C++ front-end to create the parm var decls in this case, to be consistent with "void f(int);". The typedef shouldn't affect the AST generated other than the pretty type.

Long term, I'd love to get rid of parm var decls in the common case. They are needed for stuff like this in C:

void f(int i, int x[i*42]);

etc. However, this is obviously not the common case, and most clients don't care about parmvardecls in function prototypes. Considering that tons of headers have lots of function prototypes, I think this would be a big win. This isn't a particularly high priority though,

-Chris

Chris Lattner wrote:

Two options here. The best is probably for the C++ front-end to create the parm var decls in this case, to be consistent with "void f(int);". The typedef shouldn't affect the AST generated other than the pretty type.

If the C++ front-end could be changed to handle the no-parmvardecl case, it would also work in the case that not producing them is common.
In general I think there should be some convention, whether they are produced or not should be the same for both front-ends. Producing them for C++ and not for C is more confusing.

-Argiris

Chris Lattner wrote:-

> e.g:
>
> typedef void fn(int);
> fn f;
>
> There are no ParmVarDecls created for the 'f' FunctionDecl, and I
> assume
> this is intended to save space.
> This crashes the C++ front-end when trying to use the ParmVarDecls
> (mostly for handling default args).
>
> In C there is no problem since ParmVarDecls are used only for
> definitions, otherwise FunctionTypeProto is used

Two options here. The best is probably for the C++ front-end to
create the parm var decls in this case, to be consistent with "void
f(int);". The typedef shouldn't affect the AST generated other than
the pretty type.

Long term, I'd love to get rid of parm var decls in the common case.
They are needed for stuff like this in C:

void f(int i, int x[i*42]);

etc. However, this is obviously not the common case, and most clients
don't care about parmvardecls in function prototypes. Considering
that tons of headers have lots of function prototypes, I think this
would be a big win. This isn't a particularly high priority though,

It depends how much info you wish to store. The C standard says the
above is equivalent to

  void f(int, int [*]);

so you could store it as that if you're willing to lose the i and the x.

Neil.

Chris Lattner wrote:

Two options here. The best is probably for the C++ front-end to create
the parm var decls in this case, to be consistent with "void f(int);". The
typedef shouldn't affect the AST generated other than the pretty type.

If the C++ front-end could be changed to handle the no-parmvardecl case, it
would also work in the case that not producing them is common.

Yes.

In general I think there should be some convention, whether they are
produced or not should be the same for both front-ends. Producing them for
C++ and not for C is more confusing.

I think Argiris is voicing an important principle here: regardless of
what dialect we're parsing, we should produce ASTs of the same form.
Having the ParmVarDecls or not shouldn't be a C-vs-C++ decision, but
there could be a function-definition-vs-non-function-definition
decision. Sometimes the same syntax has different interpretations in
different dialects---"void f();" in C vs. C++, for example---but the
notion of a function "f" with no prototype or of a function f" that
accepts no arguments and has a void return type is always the same in
the AST.

  - Doug

Added a bug report for keeping track:
http://llvm.org/bugs/show_bug.cgi?id=2942

Doug Gregor wrote:

I agree completely,

-Chris