The DWARF Importer does not yet know how to answer a request at the level of a single member. All the tests that saw this as an observable behavior were actually seeing a complete cache fill from lazy member loading an initializer fail over to flushing the member table and rebuilding it by forcing all the members. Given that the cache flush is something we're trying to avoid in general, this is obviously undesirable behavior.
Now that we're no longer flushing the cache for initializers, the DWARF Importer needs to simulate the old behavior and completely deserialize members of loaded types. This pessimization is justified anyways, considering if you're loading from DWARF, you're probably about to print the type and its fields anyways.
Removes duplicated logic from the implementations of
FileUnit::lookupValue, and simplifies the interface to
ModuleDecl::lookupValue, where everyone was passing an empty
(non-filtering) access path anyway /except/ during actual lookup from
source code. No functionality change.
We already do this for other ASTContext-allocated types (see
Decl.cpp). This will prevent the sort of mistakes in the previous two
commits.
Note that if any particular subclass of FileUnit wants to have its
destructor run, it can opt into that manually using
ASTContext::addDestructorCleanup. SourceFile and BuiltinUnit both do
this. But we generally don't /want/ to do this if we can avoid it
because it adds to compiler teardown time.
This refactors DWARFImporter to become a part of ClangImporter, since
it needs access to many of its implementation details anyway. The
DWARFImporterDelegate is just another mechanism for deserializing
Clang ASTs and once we have a Clang AST, the processing is effectively
the same.