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

[Douglas Gregor]

On Mar 12, 2013, at 5:26 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

> 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.

Yes, I think this is the right way forward.

> 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.


This LGTM.

	- Doug