Added DiagnosticsDriver.def and DiagnosticsDriver.h for driver-only diagnostics.
(Diagnostics which are shared with the frontend remain in
DiagnosticsFrontend.{def,h}.)
Added a DiagnosticEngine& to Compilation, so that it can emit diagnostics for
events which occur while performing Jobs.
Replaced all of the locations where we were manually printing error messages to
emitting real diagnostics, adding diagnostics if necessary.
Updated Driver::buildCompilation() so that it fails early if any errors were
encountered.
Updated test/Driver/actions.swift to pass a -module-name for multi-input tests.
Swift SVN r13175
This will occur if -emit-{library,executable} and -emit-module is passed but -g
is not, since both the LinkJobAction and the MergeModuleJobAction will be
top-level actions.
Swift SVN r13139
...as well as the target triple, include paths, and whether or not we're
compiling with debug info. (The last one doesn't currently make any
difference, but it seems prudent to be consistent.)
<rdar://problem/15930675>
Swift SVN r13080
Since the driver may create only some of the diagnostics files it was asked to
create, start by removing all diagnostics files so clients can detect the
presence of one to determine if the command which creates it actually ran.
This is important so that clients do not mix old and new diagnostics files,
which may occur in the event of a compilation error.
Swift SVN r13074
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
...when no -module-name or -o is provided.
This makes the single-file compile /very/ easy: compiling "foo.swift"
produces an output named "foo", rather than "a.out". For multi-file
modes, the module name is used if -o is missing; if no module name is
provided, it defaults to "main".
In a nutshell:
explicit -o > explicit -module-name > single file's stem name > "main"
<rdar://problem/12593849>
Swift SVN r12841
Centralized the driver-level handling of the SDK path in OutputInfo and
Driver::buildOutputInfo(), and added support for falling back to getenv(SDKROOT)
if -sdk wasn't passed (and SDKROOT is set in the environment).
Updated Swift::constructJob() to get the SDK path from the OutputInfo instead of
just passing -sdk from the original driver invocation.
Also added a driver-level check to ensure that the specified SDK is present;
if not, print out a warning. This fixes <rdar://problem/14409974>.
Added test/Driver/sdk.swift to test the -sdk and SDKROOT behavior, as well as
the nonexistent SDK warning.
Swift SVN r12815
In Driver::buildJobsForAction(), consult the OutputFileMap if we're building a
Job for a CompileJobAction and we're not in SingleCompile mode.
Swift SVN r12774
Added an -output-file-map option which will specify the path to an
OutputFileMap.
Added Driver::buildOutputFileMap(), which constructs an OutputFileMap
from the arguments.
Added OutputFileMap* parameters to Driver::buildJobs() and
Driver::buildJobsForAction(). (These parameters are not yet honored, except to
pass to calls of these functions.)
Swift SVN r12772
OutputFileMap is responsible for loading an "output file map", which maps input
paths (as specified on the command line) to per-output-kind paths.
This will permit the explicit specification of the outputs of each frontend
invocation: the primary output (e.g. "object" or "sil"), as well as the partial
swiftmodule and serialized diagnostics outputs (if requested).
The format (in JSON) is:
{
<input> = {
<kind> = <path>,
<kind> = <path>,
...
},
<input> = { ... },
...
}
Swift SVN r12771
Since a CommandOutput may have multiple outputs, print any additional outputs
after printing the primary output, using the following format:
... output: {<type>: "<primary output>", <type>: "<additional output>", ...}
Swift SVN r12690
The new format is "-<option>" and "-<option>-path". As a result:
- Renamed -serialized-diagnostics-path to -serialize-diagnostics-path.
- Renamed -module-output-path to -emit-module-path.
Swift SVN r12614
Added a SerializedDiagnostics entry to Types.def.
In Driver::buildJobsForAction(), set an appropriate path for serialized
diagnostics, if requested. In Swift::constructJob(), check for an additional
SerializedDiagnostics output to determine if -serialize-diagnostics and
-serialized-diagnostics-path should be passed.
This is necessary infrastructure for the output file map.
Swift SVN r12613
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
