for a DeclContext, and fix propagation of exception specifications along
redeclaration chains.
This reverts r232905, r232907, and r232907, which reverted r232793, r232853,
and r232853.
One additional change is present here to resolve issues with LLDB: distinguish
between whether lexical decls missing from the lookup table are local or are
provided by the external AST source, and still look in the external source if
that's where they came from.
llvm-svn: 232928
When we need to build the lookup table for a DeclContext, we used to pull in
all lexical declarations for the context; instead, just build a lookup table
for the local lexical declarations. We previously didn't guarantee that the
imported declarations would be in the returned map, but in some cases we'd
happen to put them all in there regardless. Now we're even lazier about this.
This unnecessary work was papering over some other bugs:
- LookupVisibleDecls would use the DC for name lookups in the TU in C, and
this was not guaranteed to find all imported names (generally, the DC for
the TU in C is not a reliable place to perform lookups). We now use an
identifier-based lookup mechanism for this.
- We didn't actually load in the list of eagerly-deserialized declarations
when importing a module (so external definitions in a module wouldn't be
emitted by users of those modules unless they happened to be deserialized
by the user of the module).
llvm-svn: 232793
declarations. We can't expect to find them in the canonical definition
of the class, because that's not where they live.
This means we no longer reject real ODR violations with friend declarations,
but we weren't consistently doing so anyway.
llvm-svn: 216369
If we have multiple definitions of the same entity from different modules, we
nominate the first definition which we see as being the canonical definition.
If we load a declaration from a different definition and we can't find a
corresponding declaration in the canonical definition, issue a diagnostic.
This is insufficient to prevent things from going horribly wrong in all cases
-- we might be in the middle of emitting IR for a function when we trigger some
deserialization and discover that it refers to an incoherent piece of the AST,
by which point it's probably too late to bail out -- but we'll at least produce
a diagnostic.
llvm-svn: 192950
Richard Smith