All of these are tools that are only meant to be used when testing swift. Thus
it doesn't make sense to include them in the catch all 'tools' install component
that distributions use to build all the tools.
I verified that all of the mac/linux presets in tree that have tools also has
testsuite-tools so this should be NFC. On Windows, I needed to add
testsuite-tools to build-windows.bat so should be NFC there as well.
A follow-up PR adds a flag to control an inline namespace that allows
symbols in libDemangling to be distinguished between the runtime and
the compiler. These dependencies ensure that the flag is plumbed
through for inclusions of Demangling headers that aren't already
covered by existing `target_link_libraries`.
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.
When debugging Objective-C or C++ code on Darwin, the debug info
collected by dsymutil in the .dSYM bundle is entirely
self-contained. It is possible to debug a program, set breakpoints and
print variables even without having the complete original source code
or a matching SDK available. With Swift, this is currently not the
case. Even though .dSYM bundles contain the binary .swiftmodule for
all Swift modules, any Clang modules that the Swift modules depend on,
still need to be imported from source to even get basic LLDB
functionality to work. If ClangImporter fails to import a Clang
module, effectively the entire Swift module depending on it gets
poisoned.
This patch is addressing this issue by introducing a ModuleLoader that
can ask queries about Clang Decls to LLDB, since LLDB knows how to
reconstruct Clang decls from DWARF and clang -gmodules producxes full
debug info for Clang modules that is embedded into the .dSYM budle.
This initial version does not contain any advanced functionality at
all, it merely produces an empty ModuleDecl. Intertestingly, even this
is a considerable improvement over the status quo. LLDB can now print
Swift-only variables in modules with failing Clang depenecies, and
becuase of fallback mechanisms that were implemented earlier, it can
even display the contents of pure Objective-C objects that are
imported into Swift. C structs obviously don't work yet.
rdar://problem/36032653
Rather than using the `LINK_LIBRARIES` option, use target_link_libraries
like clang does. Because these are all host tools, there is no name
mangling done for the libraries making this a no-op change.
Remove the unncessary link against the DebugInfoCodeView component. THe tools
seem to build without the dependency. The dependency issue in the linkage
seems to have been resolved.
The main action here is to sink the creation of the installation rule for all of
the swift host tools into this API. In a latter commit, I will use this API to
create include and build rules for add_swift_host_tool.
All of these cases seem to need the symbols from LLVM's new CodeView library to
link.
The specific executables are:
1. Swift Driver.
2. SIL Extract.
3. SIL Opt.
4. Swift IDE Test.
5. Swift LLVM Opt.
6. LLDB Module Import Test
Add tools/lldb-moduleimport-test, which simulates LLDB importing modules
from the __apple_ast section in Mach-O files and use it to regression-test
the new API.
Swift SVN r7709
