(when in -emit-library mode)
The one catch is that if you specify an output file named "libFOO" with no
extension, the module name will still be "libFOO", not "FOO". Explicitly
providing both -o and -module-name is always allowed.
<rdar://problem/17827584>
Swift SVN r20869
Without this, clients that don't use a CompilerInstance (like LLDB) won't
have target configuration options available.
Also, move minimum OS checking into the driver. This makes sure the check
happens early (and only once), and in general fits the philosophy of
allowing the frontend to use configurations that might be banned for users.
<rdar://problem/17688913>
Swift SVN r20701
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 flag is now obsoleted by the interactive driver and simply
complicates understanding the command-line parsing. Making it an error
to force users to move also allows us to reuse the flag in the future if
we like.
Swift SVN r20641
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
Now that we invoke dsymutil before cleaning up temporaries, we don't need to
keep them around for later debugging.
<rdar://problem/16877574>
Swift SVN r20530
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
Most of the tests just got moved to swiftc, but some of them were
duplicated to apply to both swiftc and swift. A handful still use the
existing 'swift' because they are for the existing '-i' syntax.
Note: this means config.swift_driver now uses the staging symlink
'swifti'. The only thing preventing us from dropping the 'i' and getting
rid of the old interface is that Xcode hasn't moved to swiftc yet
<rdar://problem/17769327>.
Swift SVN r20467
... 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
