3 Commits

Author	SHA1	Message	Date
Douglas Gregor	5c193c7ed6	When we're performing name lookup for a tag, we still allow ourselves ... to see hidden declarations because every tag lookup is effectively a redeclaration lookup. For example, image that struct foo; is declared in a submodule that is known but hasn't been imported. If someone later writes struct foo *foo_p; then "struct foo" is either a reference or a redeclaration. To keep the redeclaration chains sound, we treat it like a redeclaration for name-lookup purposes. llvm-svn: 147588	2012-01-05 01:11:47 +00:00
Douglas Gregor	0abc262b02	When we make a previously-deserialized module definition visible, ... notify the AST deserialization listener so that the AST writer knows that it can write the macro definition. llvm-svn: 146994	2011-12-20 22:06:13 +00:00
Douglas Gregor	21823bfe31	When performing name lookup for a redeclaration, ignore module ... visibility restrictions. This ensures that all declarations of the same entity end up in the same redeclaration chain, even if some of those declarations aren't visible. While this may seem unfortunate to some---why can't two C modules have different functions named 'f'?---it's an acknowedgment that a module does not introduce a new "namespace" of names. As part of this, stop merging the 'module-private' bit from previous declarations to later declarations, because we want each declaration in a module to stand on its own because this can effect, for example, submodule visibility. Note that this notion of names that are invisible to normal name lookup but are available for redeclaration lookups is how we should implement friend declarations and extern declarations within local function scopes. I'm not tackling that problem now. llvm-svn: 146980	2011-12-20 18:11:52 +00:00