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
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
Added support for the -emit-module and -module-output-path options. -emit-module
and -module-output-path function similarly to -serialize-diagnostics and
-serialized-diagnostics-path: notably, -module-output-path implies -emit-module,
but -emit-module can be passed without -module-output-path and a default path
will be determined based on other inputs.
Added support for the -module-link-name option, which specifies the name of the
library to link against when importing the generated module.
Note that support for these options is only implemented in the integrated
frontend; driver-level support for these options is forthcoming.
Swift SVN r12301
Reworked the -serialize-diagnostics option, so that it is now just a flag
indicating that the frontend should generate serialized diagnostics. The path at
which the diagnostics will be serialized is now specified by the
-serialized-diagnostics-path option, which is a frontend-only option. (The
frontend treats -serialized-diagnostics-path as implying -serialize-diagnostics.)
If -serialize-diagnostics is passed but -serialized-diagnostics-path is not
passed, the frontend will choose an output path from a few default values:
- If the frontend has a non-stdout output path, replace that path's extension
with .dia.
- If there is a primary input filename, use that input's base name as the base
name for the serialized diagnostics file.
- Otherwise, use the module name as the base name for the serialized diagnostics
file.
Added support for setting up a serialized diagnostics DiagnosticConsumer in
frontend_main() if FrontendOptions::SerializedDiagnosticsPath is non-empty.
Swift SVN r12251
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
We should be able to cut out another layer of IRGen grime now.
This does XFAIL one test, test/Prototypes/TextFormatting.swift, which fails because of a weird archetype ordering in a nested substitution list. This should get sorted out by switching to interface types, so I'm going to let it go until then.
Swift SVN r11618
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 PrintHelp and PrintHelpHidden to FrontendOptions.
Marked both -help and --help-hidden with the FrontendOption flag.
Updated ParseFrontendArgs to parse -help and --help-hidden.
Updated frontend_main() so that it prints the help for the frontend options.
Swift SVN r11320
Added a new DiagnosticOptions class to swiftBasic, and added a DiagnosticOptions member to CompilerInvocation.
Added a static ParseDiagnosticArgs function to parse diagnostic-related arguments.
Added -verify to FrontendOptions.td, and added support for parsing -verify in ParseDiagnosticArgs.
Updated frontend_main() to enable and trigger the DiagnosticVerifier when -verify is passed.
Swift SVN r11318
Added a new static ParseLangArgs, which fills in a LangOptions object.
Also moved the handling of -debug-constraints out of the loop in CompilerInvocation::parseArgs() and into ParseLangArgs, now that it has a proper home.
Swift SVN r11172
Also updated test/Driver/basic.swift to pass '-module-name basic', since the
inferred module name for the test is not a valid identifier.
Swift SVN r11111
- 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
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
