[cfe-dev] VarDecl hierarchy (Re: Objective-C tidy up)

[David Chisnall]

On 8 Jun 2008, at 18:42, Chris Lattner wrote:

> On Jun 8, 2008, at 10:30 AM, David Chisnall wrote:
>>>> It should be working now (does for me, at least...).  Assignments  
>>>> to self were failing because implicit params are not valdecls and  
>>>> I missed a test.
>>>
>>> Getting closer!  We now just have the NSString.m failure:
>>>
>>> /Users/sabre/llvm/tools/clang/lib/Analysis/../../include/clang/ 
>>> Analysis/Visitors/CFGRecStmtDeclVisitor.h:66: failed assertion  
>>> `false && "Subtype of ScopedDecl not handled."'
>>
>> I think this is fixed, but since this test only runs on OS X I  
>> can't test it...
>
> Thanks!  This gets it onto the next assertion:
>
> /Users/sabre/llvm/tools/clang/lib/Analysis/../../include/clang/ 
> Analysis/Support/ExprDeclBitVector.h:41: failed assertion `isValid()'
>
> Here's a .mi file.  Run with -checker-cfref -verify.
>
> <NSString.mi.gz>
>
>
> It would probably be useful to grep for other uses of VarDecl and  
> ParamVarDecl to see if the code applies to self as well.  There may  
> be other codepaths not being exercised by the testsuite.

It seems that there are a lot of bits of the analyses that assume  
VarDecls.  This is a bit messy, since ParmVarDecls, as VarDecl  
subclasses, store a SClass which is always None and their Init pointer  
is always 0.

This makes me wonder why ParmVarDecls are VarDecl subclasses, since  
they never actually use any of the extra state declared in VarDecl as  
far as I can see.

I'm not sure what the best approach here is.  I could make  
ImplicitParamDecl a subclass of VarDecl, which would waste a bit of  
space in every one (the same space that's wasted in ParmVarDecls).   
Changing every bit of code in the analyses that thinks it wants a  
VarDecl to expect a ValueDecl and dyn_cast it to a VarDecl when it  
actually wanted to use it as one would require some quite invasive  
changes to the code.

Suggestions?

David