Things that happen if no checker evalCall()s a function
============================================
- Invalidating ivars of ObjC message receiver
- Invalidating ivars of 'this' for C++ method call
- Invalidating args
  - okay to ignore DoNothingByRef, see below
- Invalidating globals (as part of state->invalidateRegions call)
- Conjuring return values
- Generating a new node after doing all this


RetainReleaseChecker
====================
- Registering BindingsPrinter

- *** Retain summaries in CFBugReports ***
  - Summaries are associated with ExplodedNodes in a DenseMap
    a) Inefficient? not every call needs a summary
    b) Checker functions are const

- *** Persisting ref states after invalidating receiver and arguments ***
  - Can't whitelist like we do now
  - What happens if another checker claims evalCall?
    - Are refcounts still persisted? Do we stop tracking? Do we say it escapes?
    - Do other checkers get a choice to reason about ref counts?

- Updating ref states based on arg/receiver/ret effects (PostStmt?)
  - Can't just be evalCall now that we have attributes

- Alias/ReceiverAlias effects
  - right now, evalCall is best bet
  - if we ever introduce __attribute__((return_alias)), we're in trouble
    - claiming evalCall on the basis of an attribute is a bad precedent IMHO

- evalCall for things we actually know how to eval
  - this probably isn't everything in getSummary(const FunctionDecl *).
  - instead, this should only be functions we can ENTIRELY model:
    - NSMakeCollectable, CF*MakeCollectable
    - CFRetain, CFRelease, CGRetain, CGRelease, CGCFRelease (?)
  - everything else should be handled in PostStmt
    - probably including the arg/receiver/ret effects of these, too

- funny case for DoNothingByRef, meaning "don't invalidate arg regions"
  - currently only used by CFDictionaryCreate -- maybe we just EvalCall that
    somewhere else
  - why isn't this used for CFArrayCreate?

- relegate everything else that we're just guessing about to PostStmt
  - includes Create Rule and all of the random special cases in getSummary(FD)

- evalObjCMessage? (doesn't currently exist for checkers, with good reason)
  - Almost required for:
    -[NSAutoreleasePool addObject:]
    -[NSAutoreleasePool init]
  - Nice to have (because of ReceiverAlias)
    -retain
    -autorelease
  - every other selector can be handled by a postObjCMessage checker
    - and like evalCall, this includes the other arg/receiver/ret effects


"Panic" functions (sinks)
=========================
- Just make this a check::PostObjCMessage in NoReturnFunctionChecker for
  -[NSAssertionHandler handleFailureInFunction:]
  -[NSAssertionHandler handleFailureInMethod:]
- Not really part of RetainReleaseChecker anyway