This will be used to test dependency analysis by substituting a different
executable to use as the frontend.
For debugging purposes only.
Swift SVN r23272
Previously we had three separate instances of iterating from TY_INVALID+1
to TY_LAST, completely breaking type safety. Now we have a nice little
wrapper that takes a closure, which should inline down to the same thing
anyway.
Also, eliminate TY_LAST and just use TY_INVALID as our sentinel.
Swift SVN r23222
The Swift compiler is always fed the entire list of files in a module.
If it's told to track dependencies, though, it should look to see if it
actually needs to recompile all of its inputs. The first step in this is
to see which files are actually dirty, which it does by comparing the mtime
of each source file with the mtime of its output object file. If a source
file is not dirty, it only needs to be rebuilt if it depends on something
in a dirty file.
Nothing actually uses this information yet, but we can print it with
-driver-print-bindings!
Swift SVN r23221
This just adds another possible output kind and forwards it to the frontend.
Note that in builds without an output map, this will just dump the dependencies
next to the output file, which is a temp file whose name is chosen randomly.
That's not so useful, but we can fix it later.
Part of rdar://problem/15353101
Swift SVN r23220
...and rename Command to Job (previously the name of the base class).
We never generated job lists directly contained in other job lists, so
let's not even worry about this case. We may some day need to break Job
out into separate subclasses (Clang has Command and FallbackCommand in
addition to JobList), but we should be able to keep the list separate.
No intended functionality change.
Swift SVN r23144
The name -gnone was chosen by analogy with -O and -Onone. Like -O/-Onone,
the last option on the command line wins.
The immediate use case for this is because we want to be able to run the
tests with -g injected into every command line, but some tests will fail
when debug info is included. Those particular tests can be explicitly marked
-gnone.
rdar://problem/18636307
Swift SVN r22777
We use the basename to generate the private-discriminator. Why just the
basename? Because we want projects checked out in different locations to
still have a chance of generating identical binaries, and (at least for now)
private symbols still have external linkage.
Part of rdar://problem/17632175
Swift SVN r21845
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
Previously, the driver would unconditionally create a CompileJobAction if it was
in SingleCompile or Immediate mode. If there were no inputs, though, the driver
would end up asserting later because it could not create a Command for a
CompileJobAction with no inputs.
To match the behavior of the StandardCompile mode, avoid creating a
CompileJobAction if there are no inputs. (This change only affects -v, since it
disables the 'no input files' error which otherwise prevents this condition from
being hit.)
Additionally, added a test to check swiftc's behavior when no inputs are
provided.
Swift SVN r20900
This level is selected by -parseable-output. This flag is only accepted by
swiftc, since it does not make sense for any of the interactive modes.
(Currently, this level prints out the same information as Verbose, with a
"Command: " string prepended.)
Additionally, in Compilation::performJobs, set RequiresBufferedOutput to true if
parseable output was requested, since parseable output will require buffered
output.
Part of <rdar://problem/15958329>.
Swift SVN r20872
(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
