Don't indent access modifier labels, such as "public:".
Merge branch 'interprocedural-analysis' of github.com:AlisaMaas/CArrayIntrospection into interprocedural-analysis
Order doesn't matter in these pattern lists, so keep lines sorted.
Add forward declaration of a function before calling it.

Without this, clang emits an unsightly warning.
When building bitcode for tests, treat warnings as fatal errors.

This should discourage calling a function without declaring it first,
which I think has come up more than once by now.
Grammar fix.  "can not $VERB" is slightly different from "cannot $VERB".
Add a space after "//" for single-line comments.

This is a personal style preference.  I find code more readable with a bit
of extra white space here.
Add trailing newline to the end of each non-empty source file.
Don't pull in an entire header when a simple forward declaration suffices.

Gratuitous header inclusion can significantly increase build times, so you
generally want to be as minimalist as you can.
Remove unnecessary header inclusions and "using namespace" declarations.

It looks like many of these were inherited when an existing file was
duplicated to start work on a new file.  Please remember to filter out
unneeded header inclusions when doing that.  Gratuitous header inclusion
can significantly increase build times, so you generally want to be as
minimalist as you can.  Include only what you need; nothing more.
Define a typedef alias for a complex type that appears in a public API.

I don't necessarily define typedef aliases for all nontrivial template
instantiations.  But when a tricky type appears in the public API of a
class, you probably will be using that type more than once: in the method
declaration, in the method definition, and in most or all callers.  Once
a complex template instantiation is being used that frequently, giving it
a shorter name is helpful.
Make a very simple member function inlineable.

One can certainly go overboard with inline functions.  But as a simple
heuristic, if the entire computation taking place in the function body
consists of just a call to some other function, then inlining is a clear
win.
Grab a header for a boost feature that we need.

Previously we were probably picking up this header indirectly through other
things we included.
Prefer "#if 0" and "#endif" for commenting out large code blocks.

Emacs will still auto-indent and syntax-color code commented out in this
way.  When commenting out using "/* ... */", we lose that.
Open up a bit more vertical space around a class declaration.

We use single blank lines within class declarations, so I find that double
blank lines before and after them improve visual grouping.
White space fix: use consistent spacing before "{" and after "if".
Use a handy boost feature for iterating over numeric intervals.

This lets us iterate over that interval using the "for (:)" style of loop,
which I find more readable, less error-prone, and potentially even faster.
For example, it's faster in this case because we compute the loop upper
bound just once instead of calling "call->getNumArgOperands()" on every
iteration.

IMHO, with C++11 and Boost available, there are very few scenarios left
where an old-style "for (;;)" loop is still appropriate at all.
Use a handy boost feature for turning two iterators into an iterable range.

This lets us iterate over that interval using the "for (:)" style of loop,
which I find more readable, less error-prone, and potentially even faster.
IMHO, with C++11 and Boost available, there are very few scenarios left
where an old-style "for (;;)" loop is still appropriate at all.
Visually associate "*" with the symbol being declared, not with the type.

This is just a white space tweak, but it puts one in the right mindset to
understand more complex, multi-variable declarations like "int *x, y".
That declares "x" as a pointer to int, but "y" as just an int.  If you
space that out as "int* x, y" it gives a strong (but wrong) impression that
both "x" and "y" are being declared as pointers to int.
Reduce copying of containers when inserting them into enclosing containers.

The general strategy being used here is to reserve a slot in the enclosing
container *first*.  That slot will initially be filled with an empty,
newly-constructed instance of the inner container.  We hold a reference to
that inner container, and then subsequently modify it directly.  That way
we don't need to copy the inner container to insert it into the enclosing
container later, since it's already in place.