Refactoring after elr patch and before noanallockfun

[chandlerc, 2011-09-15 01:23:45]

http://codereview.appspot.com/5001042/diff/4001/lib/Analysis/ThreadSafety.cpp
File lib/Analysis/ThreadSafety.cpp (right):

http://codereview.appspot.com/5001042/diff/4001/lib/Analysis/ThreadSafety.cpp...
lib/Analysis/ThreadSafety.cpp:268: // Helper functions for modifying a lockset
Why are these helper functions rather than members? I think its fine to have
members that essentially return a cloned + modified set...

http://codereview.appspot.com/5001042/diff/4001/lib/Analysis/ThreadSafety.cpp...
lib/Analysis/ThreadSafety.cpp:270: /// \brief Return a new lockset with a lock
added to the lockset, warning if
It doesn't really warn, it 'handles'. =]

http://codereview.appspot.com/5001042/diff/4001/lib/Analysis/ThreadSafety.cpp...
lib/Analysis/ThreadSafety.cpp:273: /// \param LockExp The lock expression
corresponding to the lock to be added
There are a lot of other parameters...

http://codereview.appspot.com/5001042/diff/4001/lib/Analysis/ThreadSafety.cpp...
lib/Analysis/ThreadSafety.cpp:274: static Lockset plusLock(ThreadSafetyHandler
&Handler,
"addLock" seeems better than "plusLock"...

http://codereview.appspot.com/5001042/diff/4001/lib/Analysis/ThreadSafety.cpp...
lib/Analysis/ThreadSafety.cpp:296: Lockset minusLock(ThreadSafetyHandler
&Handler,
"removeLock"?

http://codereview.appspot.com/5001042/diff/4001/lib/Analysis/ThreadSafety.cpp...
lib/Analysis/ThreadSafety.cpp:320: AttrType *SpecificAttr =
cast<AttrType>(Attr);
Why not pass in the argument with this more specific type? Then it can be
deduced at the call site.

http://codereview.appspot.com/5001042/diff/4001/lib/Analysis/ThreadSafety.cpp...
lib/Analysis/ThreadSafety.cpp:381: void addLocks(LockKind LK, Attr *Attr, Expr
*Exp, Expr *Parent) {
Same thing, passing in Attr with the precise type will allow deduction...