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.
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.
Traditionally a serialized binary Swift module (as used in debug info)
can only be imported if all of its Clang dependencies can be imported
*from source*.
- Swift's ClangImporter imports Clang modules by converting Clang AST
types into Swift AST types.
- LLDB knows how to find Clang types in DWARF or other debug info and
can synthesize a Clang AST from that information.
This patch introduces a DWARFImporter delegate that is implemented by
LLDB to connect these two components. With this, a Clang type can be
found (by name) in the debug info and handed over to ClangImporter to
create a Swift type from it. This path has lower fidelity than
importing the Clang modules from source, since it is missing out on
Swiftication annotations and other metadata that is not serialized in
DWARF, but it's invaluable as a fallback mechanism for the debugger
when source code for the Clang modules isn't available or the modules
are otherwise not buildable.
rdar://problem/49233932
Notify clang that we handle outdate PCH files on the client side so
there's no need to display the misleading "fatal error: file '...'
has been modified since the precompiled header '...' was built".
rdar://problem/35036656
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.
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.
When cross-compiling with a swift built for another target or when
building with a pure toolchain without the resource directory containing
host content, the modulemap required for Linux may not be found. In
such a case, we should also look for the content in the SDK if one is
provided. This improves the behaviour of `swiftc` for Linux with a
standalone SDK.
The point of this flag is to avoid re-checking the whole SDK on every
build, since under many circumstances you can assume it hasn't
changed. That worked for Clang modules, but Swift cached modules also
end up with dependencies that shouldn't be updated.
rdar://problem/53279521
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.
Otherwise, there's no guarantee of binary compatibility, and whoever
turned on library evolution support shouldn't be lulled into a false
sense of security.
This is just a warning for now, but will be promoted to an error later
once clients have shaken out any places where they're doing this.
Note that the still-experimental '@_implementationOnly' opts out of
this check, because that enforces that the import doesn't make its way
into the current module's public source or binary interface.
rdar://50261171
This option stopped working when clang changed its default behaviour to
-fmodules-validate-system-headers; we now need to explicitly disable it
to preserve the behaviour of our flag.
rdar://problem/50908762
Previously 'isSystemModule()' returns true only if the module is:
- Standard library
- Clang module and that is `IsSystem`
- Swift overlay for clang `IsSystem` module
Now:
- Clang module and that is `IsSystem`; or
- Swift overlay for clang `IsSystem` module
- Swift module found in either of these directories:
- Runtime library directoris (including stdlib)
- Frameworks in `-Fsystem` directories
- Frameworks in `$SDKROOT/System/Library/Frameworks/` (Darwin)
- Frameworks in `$SDKROOT/Library/Frameworks/` (Darwin)
rdar://problem/50516314
This commit adds a new type DynamicLookupInfo that provides information
about how a dynamic member lookup found a particular Decl. This is
needed to correctly handle KeyPath dynamic member lookups, but for now
just plumb it through everywhere.
