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
r23968 wrote out a record of which source files were included in a build,
and whether they were succesfully compiled or not...and if not, whether
they were out of date because of a cascading or non-cascading dependency.
This commit uses that information to decide what files might need to be
rebuilt even if a particular input doesn't change and doesn't appear to
have any changed dependencies. The two interesting cases are:
- A file was going to be built last time, but the build was halted
because of an error. Build it this time.
- One of the files was removed and thus we've lost a source of dependency
information; rebuild everything!
rdar://problem/19270980
Swift SVN r24018
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
This emits a dynamic library as the final build product (rather than an
executable), as well as implicitly passing -parse-as-library to the frontend.
Swift SVN r12930
Introduced OutputInfo::Mode and OutputInfo::CompilerMode, which dictate how the
driver should invoke the integrated frontend. Currently, there are three
options:
- StandardCompile: invoke the frontend once-per-input, using -primary-file
- REPL: invoke the frontend as the REPL
- Immediate: invoke the frontend in immediate mode
Updated buildOutputInfo() to properly set the CompilerMode, and updated
buildActions() and Swift::constructJob() to honor the CompilerMode.
With these changes, "swift_driver" (with no inputs) and "swift_driver -repl"
should invoke the REPL, and "swift_driver -i" should invoke the frontend in
immediate mode.
Swift SVN r12547
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
