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.
LLDB needs the -swift-version because the -D__swift__ macro affects
how Clang modules are built. This currently has the really odd effect
that when debugging a Swift program that is not using the very latest
Swift version, the first "po" takes several seconds, because the
module cache needs to be rebuilt.
rdar://problem/40241256
This is in preparation for fetching informations directly from
the module instead of specifying them on the cmdline. It will
serve us better as it will mimick more accurately the way lldb
is behaving.
This refactoring moves the validation of the modules earlier
so that we can use the validation info to create the CompileUnit.
<rdar://problem/38867076>
We're going to infer all these informations from the module, but
that's a large refactoring task which I'm going to do next.
In the meanwhile, this should allow Adrian's work to be unblocked.
<rdar://problem/38720742>
Adrian already found and reported a bug, which I'm going to fix
in a later commit. Eventually this will go away, but in the meanwhile,
we should add test for this codepath.
<rdar://problem/38720742>
The only way we had to test this path was through swift-ide-test,
which takes an input a source file, instead of a serialized module.
This is not the scenario that lldb tests, hence this patch.
<rdar://problem/38323564>
Tiny start-up time optimization noticed while looking at how we do
PrettyStackTraceProgram. Also add PrettyStackTraceProgram to a few
more of our testing tools, via the new PROGRAM_START macro.
This has the effect of propagating the search path to the clang importer as '-iframework'.
It doesn't affect whether a swift module is treated as system or not, this can be done as follow-up enhancement.
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
...with a better message than the generic "older version of the
compiler" one, when we know it's actually a different version of
Swift proper.
This still uses the same internal module version numbers to check
if the module is compatible; the presentation of language versions
is a diagnostic thing only.
Speaking of module version numbers, this deliberately does NOT
increment VERSION_MINOR; it's implemented in a backwards-compatible
way.
This will only work going forwards, of course; all existing modules
don't have a short version string, and I don't feel comfortable
assuming all older modules we might encounter are "Swift 2.2".
rdar://problem/25680392
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
I also added a macro called INITIALIZE_LLVM(argc, argv) which moves this logic
into one place and should be used at the beginning of *all* binaries. It
initializes an LLVM shutdown object, sets up the pretty stack trace, and then
initializes all of the parts of LLVM. This will make it easy to update this in
the future.
The reason why a macro was required was because of llvm_shutdown_obj, an RAII
object that cleans up LLVM. It has to be at the function level scope of the main
function.
Swift SVN r31815
inside a swift ast section in an object file so it can be passed to the
linker. The driver automatically wraps merged swiftmodules iff the target
is ELF.
rdar://problem/22407666
Swift SVN r31641
Also into a separate file.
Before (swift/Serialization/SerializedModuleLoader.h):
ModuleStatus
SerializedModuleLoader::ValidationInfo
SerializedModuleLoader::ExtendedValidationInfo
SerializedModuleLoader::isSerializedAST
SerializedModuleLoader::validateSerializedAST
After (swift/Serialization/Validation.h):
serialization::Status
serialization::ValidationInfo
serialization::ExtendedValidationInfo
serialization::isSerializedAST
serialization::validateSerializedAST
No functionality change, just a lot of renaming and a bit of reorganizing.
Swift SVN r25226
...so that the debugger has the best possible chance of being able to load
the app properly.
We don't do this for frameworks today because we don't want to leak this
information into the public module; once we have a distinction between
"the module that ships with the framework" and "the module that goes into
the debug info" we can do this for frameworks as well.
Part of rdar://problem/17670778
Swift SVN r25204
Doing so is safe even though we have mock SDK. The include paths for
modules with the same name in the real and mock SDKs are different, and
the module files will be distinct (because they will have a different
hash).
This reduces test runtime on OS X by 30% and brings it under a minute on
a 16-core machine.
This also uncovered some problems with some tests -- even when run for
iOS configurations, some tests would still run with macosx triple. I
fixed the tests where I noticed this issue.
rdar://problem/19125022
Swift SVN r23683
Rather than embed AST info directly in binaries, we now include a special
symbol table entry that points to the serialized AST as a separate file.
This requires a very recent version of ld.
We still want to support the __SWIFT,__ast section in a binary because
that's how it's modeled in dSYM, so manually test both modes in
ASTSection_linker.swift.
Part of <rdar://problem/15796201>.
Swift SVN r20421
Now that the standard library depends on Clang headers, every single tool
needs to specifically avoid using the default module cache when
SWIFT_MODULE_CACHE_PATH is set.
<rdar://problem/16294222>
Swift SVN r14937
