[cfe-dev] PATCH: Cleanup function redeclaration representations

[Chris Lattner]

On May 4, 2008, at 4:16 PM, Doug Gregor wrote:
>> That's a good point. I don't have a strong opinion on whether there  
>> should
>> be a separate 'aggregate' node or not, but assuming that there is,  
>> can the
>> semantic info for a function decl refer to the aggregate one for  
>> all redecls
>> but for decl specific info you'll use separate methods ?
>
> I think, from the programmer's standpoint, it doesn't matter so much
> whether we have an 'aggregate' decl or not, so long as it looks like
> we have an aggregate declaration.

Right.  I look at the aggregate decl is just a cache.  When it comes  
to serialization/deserialization, we may choose to not even write it  
out, because it can be fully reconstructed from the information  
available in the other decls.

> However, if we have to reconstruct the contents of the aggregate
> declaration every time we query the FunctionDecl, it's going to get
> expensive because we'll be traversing the list of redeclarations and
> accumulating information. (For example, think of merging attributes
> every time we query an attribute!)

Exactly!

>> I mean, getbody() would return the body of the aggregate for all  
>> redecls,
>> but you would also have a isThisDefinition() to probe the specific  
>> decl.
>> Same for default arguments.
>> Is this practical ?
>
> It's a little trickier for default arguments, because the default
> argument is stored as part of ParmVarDecl rather than as part of the
> FunctionDecl. The DefaultArgExpr trick can get around that specific
> issue, of course.

Incidentally, I think all 'semantic' clients will really just jump to  
the aggregate decl and use it directly.  This would encourage an idiom  
like:

D->getAggregateDecl()->isInline()

vs D->isInline(), etc.  This is similar to the canonical type system.

For client that really do what to see what the user wrote, I think it  
is reasonable to expect them to handle the cases that can actually  
occur in code.  For example, if you want to rename a function f -> g,  
you have to walk the list of all redeclarations and rename each one of  
them.  This does mean that any code that does this will need to  
tolerate things like "int foo(int x = 4, int y)" though.

> Aside from that... it effectively doubles the size of the interface to
> FunctionDecl (isInline and isThisInline, getAttrs and getThisAttrs,
> etc.), but it does solve the issue without losing any source
> information. It's harder to write bad code in this case, but one is
> going to have to be very methodical when maintaining source
> information to avoid writing isFoo rather than isThisFoo.

To avoid doubling the interface, we can just require clients to get  
the aggregate version first, do you like this style or prefer to  
double the interface?

> Overall, I think this approach is an improvement.

Great!  Incidentally, is there a better name than 'aggregate' for  
these? :)  How about Accumulated or something else?

-Chris