[cfe-commits] r62003 - in /cfe/trunk: include/clang/AST/Decl.h include/clang/Basic/DiagnosticKinds.def lib/Sema/SemaDeclCXX.cpp test/SemaCXX/virtuals.cpp

[Douglas Gregor]

On Jan 9, 2009, at 1:18 PM, Sebastian Redl wrote:

> Douglas Gregor wrote:
>>
>> On Jan 9, 2009, at 11:57 AM, Sebastian Redl wrote:
>>
>>> -
>>> +
>>> +  bool isVirtual() { return IsVirtual; }
>>> +  void setVirtual() { IsVirtual = true; }
>>> +
>>> +  bool isPure() { return IsPure; }
>>> +  void setPure() { IsPure = true; }
>>> +
>>
>> Could you add some documentation for these? Just a sentence or two
>> would suffice.
>>
>
> Will do.
>
>>> +      // not static member. perhaps virtual function?
>>> +      if (CXXMethodDecl *MD = dyn_cast<CXXMethodDecl>(Member)) {
>>> +        IntegerLiteral *IL;
>>> +        if ((IL = dyn_cast<IntegerLiteral>(Init)) && IL->getValue()
>>> == 0 &&
>>> +            Context.getCanonicalType(IL->getType()) ==  
>>> Context.IntTy) {
>>
>> I'm not so sure about this. Can't the parser parse a pure-specifier
>> differently from a normal initializer, so it can check for '= 0'
>> rather than having semantical analysis try to dissect an
>> already-analyzed expression? We'll need to handle this kind of syntax
>> on the parser anyway to deal with C++0x's "= delete" and "= default".
>
> I had a comment along those lines in there originally. However, it's  
> not
> easy - it means that during declarator parsing, the parser would  
> need to
> keep track of whether the result is a function - typedefs for  
> functions
> and function pointers don't count!

That's horrible! I had expected that something like this would be ill- 
formed:

   typedef void F(int, int);
   struct X {
     virtual F f = 0;
   };

But, apparently, that's perfectly valid code, and you're absolutely  
right: there's no way to do this in the parser.

> GCC does it by analyzing the initializer too, judging from the error
> messages (try compiling the test case with GCC).
> Yes, it would be better, and I can re-add the fixme. But I just don't
> see a good way of doing it.
> default is easy, because it's not a valid part of an expression.  
> delete
> is tricky, but we could probably get away with treating it specially
> because its type is void and it's not allowed on the right side of an
> assignment anyway.


Yep, okay. Thanks for the clarification!

	- Doug