This sets OutputInfo::CompilerMode to a new SingleCompile mode, which in turn
causes the driver to create a single CompileJobAction for all inputs. This mode
also prevents the creation of a MergeModuleJobAction, since we can rely on the
frontend to generate a full swiftmodule.
This mode will allow the driver to properly compile the stdlib; if this mode is
necessary for other inputs, we can rename and publicize this option.
Swift SVN r12612
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 swift::ExecuteInPlace(), which on Unix acts as a wrapper for execv()
and execve(). On other platforms, swift::ExecuteInPlace() is a wrapper for
llvm::sys::ExecuteAndWait(), so callers must be prepared for ExecuteInPlace()
to return in a non-error situation.
Added support in Compilation::performJobs() to detect that the Compilation has
exactly one Command to run. If that's the case, and buffered output isn't
required, execute that Command using swift::ExecuteInPlace() (instead of
creating a TaskQueue, which may unconditionally buffer output).
This change will allow the driver to invoke the frontend's REPL and immediate
modes without buffering output (and, on Unix, without a separate process being
spawned).
Also updated test/Driver/basic.swift to emit output with these changes in place.
Swift SVN r12544
This will indicate that the generated module was user-requested, so it should be
placed alongside other outputs.
Updated buildOutputInfo() in a few ways:
- Updated it to set ShouldTreatModuleAsTopLevelOutput correctly.
- Updated it such that -g implies that a module should be generated, but treated as an intermediate.
- Moved the fallback ModuleName handling into buildOutputInfo(), which requires passing an InputList.
Swift SVN r12502
First, prefer -module-output-path over any other options when binding the output
for a merge module Command. If that’s not set, use the same behavior as other
intermediate outputs, but use the module name as the base name (instead of the
BaseInput, which is not descriptive enough for a swiftmodule).
This does not yet handle the case where the emitted module should be treated as
a top-level output, even though it’s not the top-level job (essentially,
whenever -emit-module is passed but the driver isn't in EmitModuleOnly mode).
Swift SVN r12500
Adjusted Driver::buildJobs() and Driver::buildJobsForAction() to include a const OutputMode& parameter.
Updated Driver::buildJobsForAction() to set an additional swiftmodule output on Jobs generated from a CompileJobAction if the OutputMode says the driver should generate a module.
This change now causes frontend invocations to pass “-emit-module -module-output-path <path>” when a module is requested, though the partial modules are not yet properly merged.
Swift SVN r12495
Instead of having buildActions() call the private Driver::getOutputMode() function, establish an OutputMode using a new Driver::buildOutputMode() function.
This change will allow the OutputMode to be more easily shared across functions without needing to generate it each time (though, at the moment, only buildActions() uses the OutputMode).
Swift SVN r12494
If the Swift tool is told to generate a command which produces a swiftmodule
additional output, pass -emit-module and -module-output-path. (Note that nothing
sets up this additional output yet; support for that is forthcoming.)
Swift SVN r12493
Updated Driver::OutputMode to also contain a ShouldGenerateModule field.
Updated Driver::getOutputMode() to set OutputMode::ShouldGenerateModule appropriately.
Updated Driver::buildActions() to insert a MergeModuleJobAction into the Action graph if the Driver’s OutputMode indicates that a module should be generated.
Swift SVN r12492
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
This will allow the driver to specify the location for, among other things, the partial swiftmodule generated by a single frontend invocation.
Swift SVN r12449
Across recursive calls to performJobsInList(), keep track of ScheduledCommands
and FinishedCommands, so we can do the following:
- Don’t schedule a Command which is already scheduled (since it may be
scheduled as a peer before we try to schedule it as an input).
- Don’t schedule a Command whose inputs have not all finished.
Swift SVN r12444
Since a Job may be reached through multiple paths in the dependency graph, we
need to include support for caching Jobs. (Currently, the cache maps
Action/ToolChain pairs to Jobs.)
As a result of these changes, Tool::constructJob() and
Driver::buildJobsForAction() return a plain Job *, instead of a
std::unique_ptr<Job>, since the Jobs returned by buildJobsForAction() no longer
need to be unique.
Swift SVN r12443
This instructs the driver to skip task execution by using a DummyTaskQueue in Compilation::performJobsInList().
This option should generally only be used for testing, as DummyTaskQueue may provide fake buffered output.
Swift SVN r12350
In Compilation, perform Jobs by scheduling Commands which need to be run (currently
all Commands, but this can be refined later) on TaskQueues by doing the following:
1. Perform all inputs to all Jobs in the current JobList. (Treat a JobList as its
own inputs for scheduling purposes.)
2. After each Command's inputs run, check to see if that Command needs to run.
If so, schedule it for execution. (Currently, all Commands always need to run.)
3. Set up a TaskFinishedCallback which will check to see if any other Commands need
to run as a result of executing a particular Command. (Currently, all Commands
depend on all other Commands.) If a Command needs to run and it is not already
scheduled for execution, schedule it for execution.
4. Ask the TaskQueue to execute. (This will call the TaskFinishedCallback as
necessary).
Swift SVN r12060
Added driver-level support for generating commands with -emit-ir and -emit-bc as well integrated frontend support for handling -emit-ir and -emit-bc.
Swift SVN r11375
Actual execution of Jobs is still performed under-the-covers by JobList::run(), but this abstraction will allow the Compilation to execute Jobs in parallel.
Swift SVN r11334
The driver does not yet support parallel execution, but this sets the Compilation up with the necessary information to execute commands in parallel.
Swift SVN r11333
In Driver::translateInputArgs(), don’t break apart the OPT__DASH_DASH argument if we’re in immediate mode.
Mark OPT__DASH_DASH as being a FrontendOption.
In Swift::constructJob(), add support for types::TY_Nothing, and pass the argument for OPT__DASH_DASH as-is if the driver is invoking the frontend in immediate mode.
Swift SVN r11325
- Added support for invoking the Swift frontend via "swift_driver -frontend".
- Added frontend_main.cpp, which implements the main entry point for the
integrated frontend. (Currently, this supports compiling an input Swift file
into an object file.)
- Removed lib/Frontend/FrontendOptions.td, and replaced its functionality with
options in include/Swift/Driver/Options.td and a new
include/Swift/Driver/FrontendOptions.td. Options supported by the frontend
are denoted by the FrontendOption flag; options which are not supported by
the driver are denoted by the NoDriverOption flag.
- Updated CompilerInvocation::parseArgs() to use the option table returned from
createDriverOptTable(), including renaming a handful of options. (-triple is
now -target, and -Xclang is now -Xcc.)
Swift SVN r11082
Instead of producing "swift_driver --version" commands, implemented support for producing
"swift" commands which actually compile code. (The support at this point is rudimentary,
but serves as a good starting point.)
Swift SVN r10949
SIL emitted by -emit-silgen is treated internally as “raw-sil”, while SIL emitted by -emit-silgen is treated internally as “sil".
Externally, there are no changes; both kinds of SIL still have a “.sil” file extension.
Updated test/Driver/Actions.swift to account for the change in behavior with -emit-silgen.
Swift SVN r10947
This produces output similar to "clang -ccc-print-bindings".
Also added several tests to ensure that "swift_driver -driver-print-bindings"
behaves as expected.
Swift SVN r10935
- 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
