A DirectoryEntryRef was added to wrap DirectoryEntrys and numerous
APIs were changed to use it in clang. Change one usage here to account
for the difference.
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.
If, while loading a bridging header, we pick up a Clang module that
claims to have an overlay Swift module, and that Swift module turns
out to have a bridging header, we can end up reallocating the array
of modules to process while we're looping over it. Be defensive
against this occurrence.
This just fixes a crash; it does not at all solve the problem of this
being broken in several ways:
- Accidentally naming your module the same as a system module shadows
the latter (if the system module is a Swift module) or *makes your
module into an overlay* (if the system module is a Clang module).
- Bridging headers are only officially supported on executable targets
and unit tests, but this isn't really enforced.
- Implicit inclusion of a bridging header *when you import a Swift
module* is a hack to begin with, and a hack that worsens when the
main module also has a bridging header. (All the bridging headers
get folded together into the "same" module, which leads to more
visibility than desired as well as cycles in the import graph.)
- Combining all of these can result in some pretty bizarre behavior.
rdar://problem/54581756
A DirectoryEntryRef was added to wrap DirectoryEntrys and numerous
APIs were changed to use it in clang. Change one usage here to account
for the difference.
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.
Add a comment to the ClangImporterDependencyCollector explaining that
the FileCollector is used by LLDB to generate reproducers and is not
involved in dependency collection in Swift.
(cherry picked from commit 0a9149f357)
For reproducers in LLDB, we need to collect module dependency
information coming from the clang importer. However, we cannot override
the dependency collector, like we do in LLDB, because its interface is
completely hidden in the clang importer. The solution is to pass the
FileCollector through the DependencyTracker.
(cherry picked from commit c624a87bd5)
The clang importer has to deal with two virtual file systems, one coming
from clang, and one coming from swift. Currently, if both are set, we
emit a diagnostic that we'll pick the swift one.
This commit changes that, by merging the two virtual file systems. The
motivation for this change is the reproducer infrastructure in LLDB,
which adds a third virtual file system to the mix.
(cherry picked from commit 94ef5431ff)
Change Swift to work with the new FileManager API. It now returns and
ErrorOr<FileEntry*> instead of just the raw pointer.
(cherry picked from commit 257dbcd49d)
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances in the swift repo.
