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

Argiris Kirtzidis akyrtzi at gmail.com
Mon Sep 8 16:14:33 PDT 2008


Hi Doug,

I don't quite see why it's necessary to have an "Overload" type and an 
OverloadedFunctionDecl AST node.
It seems to me that these are mainly used for name lookup, and 
IdentifierResolver can be used for such a thing without introducing 
OverloadedFunctionDecl.
I've attached a patch where I replace the use of OverloadedFunctionDecl 
by using IdentifierResolver (passes the test case), to show you what I mean.

AST clients may need a set of overloaded functions but I think that this 
can be provided by utility functions (or by chaining the FunctionDecls).

Let me know what you think.

-Argiris

Doug Gregor wrote:
> This patch implements support for declaring overloaded functions. For
> example, one can now write
>
>   void f();
>   void f(int);
>   void f(int, float);
>
> and have these functions overloaded appropriately. Name lookup for "f"
> will refer to the overload set, although at this point you can't actually do
> anything with the overload set (that patch is coming later).
>
> All of the semantic analysis required to distinguish between
> redeclarations and overloads is implemented. Most of the interesting
> logic is in the new Sema::IsOverload, which determines whether two
> function declarations are overloaded and in Sema::MergeFunctionDecl,
> which produces diagnostics when two function declarations with the
> same signature (meaning: they aren't overloads) aren't declaring the
> same function.
>
> The new OverloadedFunctionDecl class stores a set of overloaded
> functions. It's generated by Sema when one declares an overload of an
> existing function. Name bindings for functions can refer to
> OverloadedFunctionDecl nodes, which will store all of the functions in
> that scope with that name.
>
> Patch notes:
>
> - An OverloadedFunctionDecl never owns the FunctionDecls it
>   stores. The scope where those FunctionDecls were declared owns
>   them. However, who owns the OverloadedFunctionDecl? It's required
>   for semantic analysis, and will need to be retained for use in
>   qualified name lookup later, but it doesn't belong with all of the
>   decls written by users.
>
> - The type of an OverloadedFunctionDecl is a special builtin
>   "Overload" type, used as a placeholder for OverloadedFunctionDecls.
>
> - When we redeclare a function, we now replace the existing name
>   binding for that function with the new declaration. This way, there
>   will only be one name binding for a given function in a given scope
>   at a time, rather than one for each (re)declaration of that
>   function. (This is important for function overloading, because we
>   don't want redeclarations to look like overloads). In this patch,
>   all of the function declarations and redeclarations show up as they
>   always have, the AST will contain references to whichever function
>   declaration was active that the time that part of the AST was
>   generated [*], but we don't end up with multiple bindings to the
>   same function in the same scope.
>
> [*] http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-May/001801.html
>
> - When we overload a function, we replace the existing name binding
>   (which will point to a FunctionDecl) with an OverloadedFunctionDecl
>   that contains the original FunctionDecl and the new FunctionDecl.
>
> - In C++ mode, we now create a FunctionTypeProto for "void f()" rather
>   than a FunctionTypeNoProto.
>
> Comments greatly appreciated.
>
>   Cheers,
>   Doug
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: func-overload.patch
Type: text/x-diff
Size: 14021 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080908/26c6e595/attachment.patch>


More information about the cfe-dev mailing list