This was just a wrapper around SmallVector that optionally owned the Job pointers
in it. Now that all Jobs are owned by the Compilation, we don't have to worry
about this any more.
No functionality change.
Swift SVN r29668
...not if it's newer than its output .o file. This handles cases where the
object file is generated too quickly (rdar://problem/19404140) or when you
revert to a previous version of the file, mtime intact (rdar://problem/19720146).
There's a lot of test churn here; the only real new test is the backwards
mtime update in one-way.swift.
Swift SVN r29584
Together with -wmo it enables multi-threaded compilation.
I didn't want to reuse the -j option for this, because -num-threads (even if n == 1) does change the generated code.
For details see commit message of r25930.
Swift SVN r26258
These aren't inherently incompatible, but today it would do nothing useful,
and using both flags together causes problems (see previous commit).
rdar://problem/19669432
Swift SVN r25389
Also, normalize the target triple up front, so that we're never dealing
with non-normalized triples in the driver unless explicitly asking for
the original user option.
rdar://problem/18065292
Swift SVN r24563
If certain command-line arguments change, the results of the last
compilation aren't reusable, i.e. we can't do an incremental build.
Do a full rebuild when we detect that this happens.
(Which command-line options? Conservatively assume all of them, /except/
those with the new DoesNotAffectIncrementalBuild flag in Options.td.)
Swift SVN r24385
of 'bin/swift-update' with the related frontend options.
'swift-update' will be the tool for producing diffs to update swift code to the
latest version.
Swift SVN r24287
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
Actually, reject SDK directories whose names match
"*OSX<version>(.Internal)?.sdk" on OS X with a version older than 10.10
"*OS7*" on iOS
"*Simulator7*" on iOS
We only really care about 10.9 anyway, but just in case people install the
one-previous version of iOS...
<rdar://problem/17951615>
Swift SVN r21100
There are two valid values for this: 'swift' and 'swiftc'. This flag must be
specified as the first option; otherwise, it will be ignored. This flag allows
the caller of the driver to force 'swift' to behave as 'swiftc', or vice versa,
and is useful in situations where the name of the executable cannot be changed.
Swift SVN r20656
This makes the command line interface to 'swift' the same as what was
previously in 'swifti', and removes the staging symlink.
For posterity, the command line behaviour for 'swift' is now:
* `swift` -> start the repl
* `swift script.swift` -> run script.swift (the old -i mode)
* Any arguments after the input file are forwarded to the script as
Process.arguments
* A shebang line is something like #!/usr/bin/xcrun swift
The batch compiler 'swiftc' behaves much like the old 'swift'
executable, but without the interactive bits now in 'swifti'.
<rdar://problem/17710788>
Swift SVN r20540
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
For now, keep 'swift' the same and put all the interactive driver
changes under 'swifti'. When these are in good shape, I will remove
swifti and make 'swift' the interactive driver as discussed.
Swift SVN r20359
If a temporary file is mentioned in the output map, it is also preserved.
We can make a nicer -save-temps later, but for now this will at least stop
leaving random files in /var/tmp.
<rdar://problem/16874893>
Swift SVN r17850
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
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
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
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
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
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 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
