[cfe-dev] PATCH: Overloaded function declarations in C++

[Daniel Dunbar]

> The problem is that OverloadedFunctionDecls can show up as children of
> other AST nodes. For example, in
>
>  void f(int); // #1
>  void f(float); // #2
>  (f)(1.5);
>
> we'll end up building a
> ParenExpr(DeclRefExpr(OverloadedFunctionDecl)). Keeping track of the
> (f) without using AST nodes seems like it could get messy.

Ok. I agree this might get messy.

>> Adding "fake" AST nodes
>> to accomodate this seems outside the current design spirit and I think may
>> spread complexity into places that don't deserve it.
>
> I don't agree that it's a "fake" AST node. An overloaded function name
> is a full-fledged concept in C++ semantic analysis. And even though
> semantic analysis can remove these OverloadedFunctionDecl nodes now,
> they'll need to be stored in the AST for templates (which must keep
> track of overload sets explicitly, to be used again at instantiation
> time).

My impression was that these nodes were only going to exist during Parsing/Sema
and not actually ever show up in the tree. If they are actually going
to need to exist
in places in the AST then it seems more reasonable to actually introduce them
(since downstream clients will have to be able to handle them anyway).

The other part that seemed fake was that they are not a "decl" in the sense of
actually defining anything or existing per se in the source. Are they
a "Decl" for
any reason other than shoehorning into the types the Parser expects? And if so,
do they need to be a ValueDecl?

Aside from its use in the decl, I don't really see why OverloadType is needed...

 - Daniel