This was being staged as -emit-reference-dependencies, but it's affecting
a lot more than that. Eventually for command line builds this should also
preserve intermediate build outputs (like .o and .swiftmodule) for use in
later builds, rather than putting them in $TMPDIR and deleting them after.
This option is still hidden.
Swift SVN r23295
This teaches the driver's Compilation to not run jobs where the base input
is older than the main output (r23221) when we're tracking dependencies.
After a compile command finishes, anything that depended on the file that
just got compiled will get scheduled.
This has the nice side effect of trying to rebuild changed files first.
The tests here aren't really testing the dependency graph yet, because the
files don't include any dependencies. I'll be adding several more test
scenarios in the next few commits.
Part of rdar://problem/15353101
Swift SVN r23273
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
...and some basic unit tests for it.
The purpose of this class is to track dependencies between opaque nodes.
The dependency edges are (kind, string) pairs, where the "kind"
distinguishes different kinds of dependencies (currently "top-level names"
and "types that we do lookup on"). The step is to make use of it in
running compile commands.
The YAML-based file format is only for bring-up and testing purposes.
I intend to switch it to a bitcode-based format in the long run.
Part of rdar://problem/15353101
Swift SVN r23223
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
Instead, if we can't schedule a command, record why it was blocked. When the
blocking command completes, we then try to reschedule everything that was
blocked on it.
This is also more robust for cross-job-list dependencies---things like the
link job depending on the merge-module job and both depending on compile jobs.
Swift SVN r23143
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
This avoids a bunch of issues trying to correctly guess parameters
for ld for linux platforms. We know we have clang, we know it should
be able to link, so use clang.
Swift SVN r22571
Previously we hardcoded a few important default CPUs, ABIs, and features into
Swift's driver, duplicating work in Clang. Now that we're using Clang's
driver to create the Clang "sub-compiler", we can delegate this work to Clang.
As part of this, I've dropped the options for -target-abi (which was a
frontend-only option anyway) and -target-feature (which was a hidden driver
option and is a frontend-only option in /Clang/). We can revisit this later
if it becomes interesting. I left in -target-cpu, which is now mapped
directly to Clang's -mcpu=.
Swift SVN r22449
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
This is enabled by default because SILGen can crash when @objc is used without importing Foundation, but
it gets disabled when compiling the Swift stdlib.
Addresses rdar://17931250.
Related test case on the SourceKit side.
Swift SVN r21319
The LLDB REPL doesn't guarantee any particular module name, and in particular
it currently uses multiple modules to handle redefinitions.
<rdar://problem/17918172>
Swift SVN r21303
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
While we work out the remaining performance improvements in the type checker, we can improve the user experience for some "runaway solver" bugs by setting a limit on the amount of temporary memory allocated for type variables when solving over a single expression.
Exponential behavior usually manifests itself while recursively attempting bindings over opened type variables in an expression. Each one of these bindings may result in one or more fresh type variables being created. On average, memory consumption by type variables is fairly light, but in some exponential cases it can quickly grow to many hundreds of megabytes or even gigabytes. (This memory is managed by a distinct arena in the AST context, so it's easy to track.) This problem is the source of many of the "freezing" compiler and SourceKit bugs we've been seeing.
These changes set a limit on the amount of memory that can be allocated for type variables while solving for a single expression. If the memory threshold is exceeded, we can surface a type error and suggest that the user decompose the expression into distinct, less-complex sub-expressions.
I've set the current threshold to 15MB which, experimentally, avoids false positives but doesn't let things carry on so long that the user feels compelled to kill the process before they can see an error message. (As a point of comparison, the largest allocation of type variable data while solving for a single expression in the standard library is 592,472 bytes.) I've also added a new hidden front-end flag, "solver-memory-threshold", that will allow users to set their own limit, in bytes.
Swift SVN r20986
Added a new API, swift::driver::createCompilerInvocation. This takes an array
of driver arguments, constructs a Driver and a Compilation, and then uses the
Compilation's frontend arguments to create a CompilerInvocation.
This works by forcing Driver to create a Compilation which contains a single
compile command. (It achieves this by passing
"-force-single-frontend-invocation" after all other arguments.) This approach
roughly matches Clang's clang::createInvocationFromCommandLine.
As implied by the namespacing, this lives in swiftDriver. As a result,
swiftDriver now depends on swiftFrontend.
In support of this, added a couple of driver diagnostics for exceptional error
cases (where Driver produced something other than a single Command, or if that
Command is not a frontend command).
This fixes <rdar://problem/16125395>.
Swift SVN r20972
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
When "-parseable-output" is passed to the driver, it will now emit output in a
parseable format. (This format is described in docs/DriverParseableOutput.rst,
which was added in a previous commit.)
This is achieved by adding four functions (one for each kind of message). These
are in a new swift::driver::parseable_output namespace, and given the right
parameters, will output the appropriate message in JSON to the given
llvm::raw_ostream. These functions are then called by
Compilation::performJobsInList:
- "began" messages are emitted by the taskBegan callback
- "finished" messages are emitted by the taskFinished callback
- "signalled" messages are emitted by the taskSignalled callback
- "skipped" messages are emitted by the handleCommandWhichDoesNotNeedToExecute
lambda
(Note that "skipped" messages will not be emitted in practice, since the driver
does not yet support partial compilation.)
This fixes <rdar://problem/15958329>.
Swift SVN r20873
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
Previously, Verbose output was not produced for this case; it is now, and this
is achieved by making performSingleCommand() a private method on Compilation
instead of a static function.
Swift SVN r20850
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
