This option (intended to be equivalent to Clang's -MD) was never fully
implemented, and is not immediately needed by Xcode. We can test this
again once it's actually needed.
Part of the migration to the new driver.
Swift SVN r13244
...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
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
First, use -driver-print-output-file-map to ensure that the map we write out is, in fact, being deserialized properly.
Then, use -driver-print-bindings to ensure that we are preferring values in the output file map to default output paths.
Swift SVN r12775
Added a test which ensures that the driver invokes the integrated frontend in a way which does not produce any errors, in order to catch mismatches between the options the driver passes to the integrated frontend and the options which the integrated frontend accepts.
Swift SVN r11105
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
These tests currently only exercise the "swift_driver -driver-print-actions"
functionality, but at this point that is the only part of the driver which is
reasonably testable without the expectation that tests will break as output
formats change.
Swift SVN r10934
Otherwise, we'll try to type-check bits of the main source file before we've
even looked at any of the supporting files.
This affects implicit multi-file mode, where "main.swift" is assumed to be
the main source file and all others are treated as library files. (See r9890.)
<rdar://problem/15526743>
Swift SVN r10795
New rules for the driver (first match):
1. -repl: no input files allowed
2. -parse-sil: one input file allowed
3. -parse-as-library: any number of input files, all treated as Library
4. one input, extension is .sil: treated as SIL
5. one input: treated as Main
6. many inputs: treated as Library by default; "main.swift" is treated as Main
If we want more control here we can also add a -main-file option to explicitly
call out the main source file, but this at least unblocks building an entire
app target (like ListMaker) with a single Swift invocation.
Swift SVN r9890
This can be used to optimize the build order in a build system. Note,
however, that no canonicalization is going on -- we're just printing
out the paths at which we found everything we imported or listed on the
command line.
Part of <rdar://problem/14899639>
Swift SVN r8013
Previously, we were finding the /first/ dot in a name, and stripping
everything after that. If that's really what someone wants to do, they
can use -module-name explicitly.
Swift SVN r7374
In this case, the output filename is taken from the module name.
swift -emit-module x/y.swift
-> x/y.swiftmodule
swift -emit-module x/y.swift -module-name z
-> x/z.swiftmodule
swift -emit-module x/y.swift -o w/
-> w/y.swiftmodule
swift -emit-module x/y.swift -o w/ -module-name z
-> w/z.swiftmodule
swift -emit-module x/y.swift -o explicit.module
-> ./explicit.module
Swift SVN r6854
