... and use them to start diagnosing unsupported mode flag and
DriverKind combinations (e.g. swifti -c, swiftc -i). Also hide the
unsupported options from -help.
Swift SVN r20452
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
Added support in Driver which allows -force-single-frontend-invocation and
-emit-objc-header[-path] to be used together in a single invocation.
Added support in tools::Swift to pass -emit-objc-header-path if an Objective-C
header was requested; this is only valid in OutputInfo::Mode::SingleCompile
mode, and an assertion enforces this.
Added a test which ensures that the same header is emitted in with
-force-single-frontend-invocation and without it.
Swift SVN r20185
This allows swiftFrontend to drop its dependency on swiftDriver, and could
someday allow us to move the integrated frontend's option parsing out of
swiftFrontend (which would allow other tools which use swiftFrontend to
exclude the option table entirely).
Swift SVN r19824
While this appears to work, it causes problems down the line -- it's a
brittle configuration for debugging, and PrintAsObjC currently doesn't
fail gracefully if you reference a bridging-header-only type in your
public interface.
We definitely want something like this to work some day, but don't have
time to fix it now. Filed <rdar://problem/17615898>.
Swift SVN r19762
The driver option -i now requires an input file as argument, and any
options after the input file will be treated as arguments to the
interpretted file.
This also renames the frontend option to -interpret, since it is parsed
as a flag, unlike -i. We could support -interpret in the driver if we
wanted, which would allow us to use --, but wouldn't work with shebang
scripts. For now, it's frontend-only.
Swift SVN r19718
After a long discussion with Daniel, the behavior of "xcrun --sdk macosx"
will always pick the best SDK to use with the Swift found by "xcrun swift".
The only case in which we have a problem is if someone has explicitly
specified the path to a Swift binary, or if someone is on 10.9 but only has
the command line tools installed (in which case they lose anyway).
In order to keep this from polluting the tests, I've changed %swift_driver
to set SDKROOT to an empty path by default. Use -sdk if you need to provide
an SDK in a test, not the SDKROOT environment variable. (This is what
everyone has been doing so far.)
This is still limited to -i and REPL modes; for compilation an explicit SDK
is still required.
<rdar://problem/14395800>
Swift SVN r18770
This only works when swift is packaged with Xcode or installed as a command
line tool, but those are the important cases.
<rdar://problem/14395800>, again.
Swift SVN r18757
If we can't determine the type of an input file, we assume it's a linker
input of some sort (like Clang does). However, if we're not actually linking,
this resulted in unused inputs, which the driver choked on.
This commit updates the driver to throw away (and diagnose) inputs that
aren't going to be compiled if they aren't going to be used later on.
It also checks that none of our non-object output types are being treated
as linker inputs, since we do have that information around.
<rdar://problem/16019895>
Swift SVN r18667
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
Since LLDB is taking over as the REPL for Swift, we eventually want "swift"
and "swift -repl" to invoke "lldb --repl" rather than the frontend. However,
we only want to do this if the LLDB that's present is related to the Swift
that's present -- we don't want to invoke some random LLDB on the system
or in some other Xcode installation. Therefore, Swift searches for LLDB--
first next to the driver, then in the usr/bin/ outside of a toolchain--
before choosing to use it.
If the user just passes -repl and an LLDB is not found relative to the
driver, the existing "integrated" REPL will be launched instead.*
If the user passes -lldb-repl and an LLDB is not found relative to the
driver, one from the user's PATH will be chosen (like the linker).
The user can also pass -integrated-repl to get the existing behavior.
"swift -frontend -repl" always uses the integrated REPL.
* Since LLDB's not quite ready to be the REPL yet, "swift -repl" still
invokes the integrated REPL. "swift -repl -experimental-prefer-lldb" tests
the new behavior; this option will become the default (and the flag removed)
in <rdar://problem/16776719>.
<rdar://problem/16776705>
Swift SVN r17134
which provides the Neon feature. Do all the necessary
plumbing to get this from the driver to the backend.
Also, support -arch arm64, and diagnose bad -arch values
instead of silently ignoring them. It's not clear to me
that we really want to support -arch as an alternative
to -target, but unless we rip it out or establish some
sort of real policy about it, it really ought to do
something approximating the right thing.
It would be nice if we could abstract enough of clang's
driver that we could re-use some of its basic logic about
tool chains and targets instaed of iteratively
rediscovering everything it does that's actually
critically important.
Swift SVN r16447
The driver infers the filename from the module file by replacing the extension,
and passes the explicit path to the swiftdoc file to the frontend. But there
is no option in the driver to control emission of swiftdoc (it is always
emitted, and name is always inferred from the swiftmodule name).
The swiftdoc file consists of a single table that maps USRs to {brief comment,
raw comment}. In order to look up a comment for decl we generate the USR
first. We hope that the performance hit will not be that bad, because most
declarations come from Clang. The advantage of this design is that the
swiftdoc file is not locked to the swiftmodule file, and can be updated,
replaced, and even localized.
Swift SVN r14914
This is mostly useful for the standard library, whose name is going to
change to "Swift" soon. (See <rdar://problem/15972383>.) But it's good DRY.
Swift SVN r13758
This isn't perfect, since /both/ show up as arguments to both the
module-merger and the linker. However, it gets the job done: each tool just
ignores the inputs it doesn't use.
Swift SVN r13470
Added an OutputLevel enum, which is used by Compilation to determine what kind
of output it should emit when performing Jobs.
In Driver::buildCompilation(), set the default OutputLevel for the Compilation
to Normal, but set it to Verbose if -v was passed. This means that, by default,
the driver will only print subtask output; this matches Clang's behavior.
Swift SVN r13255
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
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
