[cfe-dev] PATCH: Cleanup function redeclaration representations

[Argiris Kirtzidis]

Doug Gregor wrote:
> On Thu, Apr 24, 2008 at 4:36 PM, Argiris Kirtzidis <akyrtzi at gmail.com> wrote:
>   
>>> How about having a merge more like #1 <-> #2 :
>>>
>>> (1)  -#2 merges default args from #1
>>> (2)  -#2 is checked for error diagnostics about default args
>>> (3)  -#1 gets default args from #2        \ (4)
>>>       
>> -(#1)->setNextDeclaration(#2)      ----  (maybe 3,4 are performed in
>> addRedeclaration method)
>>     
>>> (5)  -#2 is returned by the parser but only #1 is visible in scope, thus
>>>       
>> all uses of the function will point to the same FunctionDecl node (#1)
>>     
>>> In the end, both #1 and #2 contain all of the information that its
>>>       
>> corresponding declarations contain.
>>     
>>> Merged default arguments become a part of both declarations.
>>> Name lookup returns #1, which has all the necessary semantic information
>>>       
>> about default args.
>>     
>>> Will this work or am I missing something ?
>>>       
>
> It will work. We'll have lost some of the information regarding what
> #1 actually declared (e.g., the default arguments it actually
> expressed), but we can probably encode that through other means.
>   

How about

(1) -#2 is checked for error diagnostics by considering default args from both #1 and #2


And in the end, only #1 gets the merged args. This is the same as only 
#2 gets the merged args.

>>  Another thing I forgot to mention is that I believe that a name should be
>> associated with the declaration that firstly introduces it in the source,
>>  not the latest redeclaration. Do you find this reasonable or does it have
>> disadvantages ?
>>     
>
> Ah, this is the philosophical point that's pushing us toward different
> solutions. I think that the name should be associated with the most
> recent redeclaration in the source, because that declaration (1) is
> closest to the user's call, and (2) has---from the language
> perspective-all of the information accumulated from the previous
> declarations. For example, here's a test case for default arguments:
>
>   void f(int i);
>   void f(int i = 0); // expected-error {{previous definition is here}}
>   void f(int i = 17); // expected-error {{redefinition of default argument}}
>
> Should the "previous definition is here" point to the first or the
> second declaration of "f"? In general, we typically refer to the
> previous declaration or previous definition of something (function,
> variable, etc.), and it seems natural to me that that would point to
> the previous declaration (or definition) in the source, rather than
> the first declaration.
>   

At least in this specific example, I think that "previous definition is 
here" should point to the decl with the
default argument. In your example it should be the second decl, but if its

  void f(int i = 0); // expected-error {{previous definition is here}}
  void f(int i);
  void f(int i = 17); // expected-error {{redefinition of default argument}}


It should be the first.
In general I think that diagnostics should find the most relevant 
declaration, which is not necessarily the last one, does this make sense ?

> Now, one point to consider is that functions aren't often declared
> multiple times, so a lot of these examples are off in the land of
> corner cases. Most functions are declared either once or twice,
> depending on whether the user has decided to separate the declaration
> from the definition. I don't know where that leads us :)
>   

Actually, I'm thinking that maybe there could be a common convention 
that, not only functions, but vars and namespaces should follow.
An extended namespace definition could be regarded as a redeclaration.

> Ah, this is the philosophical point that's pushing us toward different
> solutions.
>   

I agree that it is philosophical, thus I don't really care much about 
the name pointing to the first or the last decl.
What bothers me is the "swapping content" bit. It seems to me that 
feeding to the consumer the same pointer for, essentially, different
declaration objects is a source of complexity and possible subtle bugs, 
without much benefit.


I hope I'm not coming off as too pedantic :)


-Argiris