The driver can now schedule jobs which typecheck just-emitted module interfaces to ensure that they can be consumed later. This can be enabled manually by passing `-verify-emitted-module-interface` to the driver.
Add a new action, LoadModuleJobAction, that the driver can use to schedule a
load of a given module before we fan out and invoke the frontend multiple
times. This gives the module interface loader a chance to compile it from a
module interface before we start with parallel invocations, avoiding starting
potentially dozens of redundant compiles of a large module. Start by using this
on the standard library.
Quick fix for rdar://52839445
Previously, Actions were responsible for freeing their inputs...
except for the ones that weren't. Or the ones that were supposed
to, but then they needed to share an input, so they couldn't anymore.
If this sounds ridiculous, you're right; now Actions are just
immediately allocated and owned by the Compilation.
The graph structure of the actions is still useful for some things; in
particular, "top-level" actions get to put their outputs somewhere
permanent rather than TMPDIR. But I expect these things to get cleaned
up in the future too.
Add a -verify-debug-info option that invokes dwarfdump --verify as the last step after running dsymutil. dwarfdump is invoked with same options clang 802.0.35 uses to invoke it:
dwarfdump --verify --debug-info --eh-frame --quiet
A warning is produced if -verify-debug-info is set and no debug option is also set.
dwarfdump is failing to validate the debug info in the test verify-debug-info.swift. The failure is:
error: .debug_line[0x0000007d].row[0].file = 1 is not a valid index
https://bugs.swift.org/browse/SR-2396
Also, cluster the flags on Action into a single word. This probably doesn't
make any real difference, but it's the convention.
No functionality change.
This makes it easier to make interpreter modes behave differently from
compilation modes. Obviously that's a trade-off, since the two modes also
share plenty, but given how few of the existing CompileJobAction checks had
to be modified for the new InterpretJobAction, I think this is the right
way to go.
Groundwork for setting [DY]LD_LIBRARY_PATH ahead of time when invoking the
interpreter, which is rdar://problem/23588774.
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
With -embed-bitcode, we will invoke swift twice, once to generate the bitcode
file, the second time to perform code generation on the bitcode file.
For now, -embed-bitcode causes -incremental builds to not be incremental,
because of potential issues of mixing the two.
rdar://19048891
Swift SVN r25559
This matches Clang's behavior, though this implementation does not check
that it's actually on a platform that uses dsymutil.
<rdar://problem/16012971>
Swift SVN r20529
Since LLDB is taking over as the REPL for Swift, we eventually want "swift"
and "swift -repl" to invoke "lldb --repl" rather than the frontend. However,
we only want to do this if the LLDB that's present is related to the Swift
that's present -- we don't want to invoke some random LLDB on the system
or in some other Xcode installation. Therefore, Swift searches for LLDB--
first next to the driver, then in the usr/bin/ outside of a toolchain--
before choosing to use it.
If the user just passes -repl and an LLDB is not found relative to the
driver, the existing "integrated" REPL will be launched instead.*
If the user passes -lldb-repl and an LLDB is not found relative to the
driver, one from the user's PATH will be chosen (like the linker).
The user can also pass -integrated-repl to get the existing behavior.
"swift -frontend -repl" always uses the integrated REPL.
* Since LLDB's not quite ready to be the REPL yet, "swift -repl" still
invokes the integrated REPL. "swift -repl -experimental-prefer-lldb" tests
the new behavior; this option will become the default (and the flag removed)
in <rdar://problem/16776719>.
<rdar://problem/16776705>
Swift SVN r17134
Added a MergeModuleJobAction, which will be translated into a Command which merges swiftmodule files.
Added a MergeModule subclass of Tool, which will generate a Command which merges swiftmodule files. (Currently, it generates a Command which invokes “swift_driver -frontend -help”.)
Added ToolChain-level support for getting the MergeModule Tool.
Nothing produces MergeModuleJobActions yet; adding that to the Action dependency graph should be enough to get this going.
Swift SVN r12491
- Added a couple of new targets:
- libswiftDriver, which contains most of the driver implementation
- swift_driver, which produces the actual executable
- Added centralized version information into libswiftBasic.
- Added a new "Driver Design & Internals" document, which currently describes
the high-level design of the Swift driver.
- Implemented an early version of the functionality of the driver, including
versions of the Parse, Pipeline, Bind, Translate, and Execute driver stages.
Parse, Pipeline, and Bind are largely implemented; Translate and Execute are
early placeholders. (Translate produces "swift_driver --version" and "ld -v"
commands, while Execute performs all subtasks sequentially, rather than in
parallel.)
This is just the starting point for the Swift driver. Tests for the existing
behavior are forthcoming.
Swift SVN r10933
