[patch] Avoid computing the linkage too early. Don't invalidate it.

[Rafael Espíndola]

We currently compute linkage lazily and cache it. When the AST is
modified in ways that can change the value, we invalidate the cache.

This is a fairly brittle API, as it is easy for some code to ask for
the linkage before we have done all the necessary modifications.
Example of past bugs in this area include warnings misfiring because
of typedefs of anonymous structs or auto variables with "become"
internal because of the initializer.

All the remaining cases I have been able to find now are benign. For
example, code calling hasLinkage in decls where we still don't know
what the linkage will be, but we know that it will have one.

I would like to change the API to one where the linkage is computed
explicitly and trying to get it when it is not available will assert.
This patch is a first step in that direction. We still compute the
linkage lazily, but instead of invalidating a cache, we assert that
the AST modifications didn't change the result (or the linkage was not
computed yet). The unchanged case is mostly to cover modules, which
know the final answer by just reading it from disk.

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: application/octet-stream
Size: 19463 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130312/525a6f2a/attachment.obj>