[cfe-dev] VarDecl hierarchy (Re: Objective-C tidy up)
csdavec at swansea.ac.uk
Mon Jun 9 09:00:01 PDT 2008
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:
>>> 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:
> Analysis/Support/ExprDeclBitVector.h:41: failed assertion `isValid()'
> Here's a .mi file. Run with -checker-cfref -verify.
> 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.
More information about the cfe-dev