[cfe-dev] Additional annotations for static analysis (Objective C designated initializers)

[Ted Kremenek]

On Nov 6, 2008, at 1:08 AM, Louis Gerbarg wrote:

> On Thu, Nov 6, 2008 at 3:34 AM, Ted Kremenek <kremenek at apple.com>  
> wrote:
>>
> The net result is we carry around 1 extra bit in every class decl, but
> remove a lot of walking around in the AST during analysis.

Hi Louis,

I can see now that you want to use memoization (dynamic programming)  
to reduce the cost of looking at a class or a superclass, particularly  
if a superclass is inspected repeatedly.

That said, I don't believe that adding an attribute or bit to  
ObjCInterfaceDecl is the right way to go.  Here's why.

The "designated_initializer" attribute, as a syntactic and semantic  
construct, only makes sense for method declarations.  Adding it to  
ObjCInterfaceDecl conceptually makes little sense.  In your proposed  
patch, it would mean that "this Objective-C class contains a method  
with the "designated_initializer" attribute.

Personally I don't think this is very clean; this information can  
easily be reconstructed later (lazily) and stored in a side map for  
use by clients that want it.  It also makes things easier for other  
clients of the ASTs, e.g. refactoring clients or editors, that want to  
modify the existing ASTs.  For example, it's not conceptually  
difficult to imagine a refactoring operation that removes/adds  
methods, and that these methods can have attributes affixed to them.   
By affixing the "designated_initializer" attribute to an  
ObjCInterfaceDecl (or by having an extra bit in the object itself)  
this means that all of these clients would have to update this  
information as well if they happen to remove or add a designated  
initializer.  By keeping things like this lazy, we obviate these  
problems by design.

I think if you want to do this memoization, we should put it in the  
checker itself.  Right now the checker interface is not designed to be  
stateful, but we certainly change that.

Another thing to keep in mind is the nature of your optimization and  
whether or not it really matters.  Your particular check will be  
applied to every @implementation that occurs within a .m file.  How  
many classes will that be?  One?  Two?  Ten?  For each one of those  
class implementations, you will scan its methods and the methods of  
its superclass.  The cost is really insignificant.

The only way you would get any benefits of memoization is by caching  
this information across multiple .m files.  Since we don't perform  
cross-translation unit analysis (yet) this just isn't possible yet,  
and even if we could it's not clear that it would matter.

Thoughts?

Ted