[cfe-dev] Storage class as written in the source.

[Enea Zaffanella]

Douglas Gregor wrote:
> On Apr 16, 2010, at 11:48 PM, Enea Zaffanella wrote:

[...]

>> struct S {
>>  S();
>>  ~S();
>>  operator bool();
>> };
>>
>> extern S::S() {}
>> extern S::~S() {}
>> extern S::operator bool() { return true; }
> 
> GCC allows it (but it doesn't have any effect on translation), while EDG rejects it. C++ [class.mem]p5 explicitly calls this ill-formed:
> 
> 	A member shall not be declared with the extern or register storage-class-specifier.
> 
> We should have an Extension/ExtWarn diagnostic about the storage-class-specifier being redundant and then just drop the storage-class-specifier.
> 
>> Hence, will it be OK if we leave the extra argument in the constructors of the AST nodes above?
> 
> I don't think we should model it in the AST because (1) it's not in the language and (2) it has no effect in GCC. Do you disagree?
> 
> 	- Doug
> 

Let me try and summarize the state of things, so that you can point out 
any flaw in my reasoning:

a) any FunctionDecl node should provide the "storage class as written" 
info for the purposes of source-based applications such as pretty 
printers, code style checkers and so on;

b) the clang AST hierarchy implies that all nodes encoding C++ methods 
are FunctionDecl nodes, so that they incur no additional memory cost;

c) since GCC accepts the construct, you (wisely) suggest that clang 
should allow for the same extension and maybe issue corresponding 
diagnostic.

The combination of a), b) means that the AST is already able to model 
this info, whereas c) means that you are willing to add the 
corresponding logic ... so I cannot see where is the problem.

If the problem is that you do NOT like having an additional argument in 
the C++ constructor for classes derived from CXXMethodDecl, then we can 
workaround this while still having this info in the AST.

For instance, we can:

A) let this argument have default value FunctionDecl::None; or

B) completely remove the argument from the CXXConstructorDecl, 
CXXDestructorDecl and CXXConversionDecl constructors and instead call 
method FunctionDecl::setStorageClassAsWritten if and when needed.

As for my personal taste, I would go for option A.

Are there other issues we are still missing?

Regards,
Enea.