For now, just error out at the end of the build if something was modified,
forcing a rebuild. The incremental logic should get that rebuild right.
We could automatically restart the rebuild, but that could lead to infinite
compilation if the user continues to edit an important file.
DerivedArgList has a pointer to the InputArgList it came from, so we can't
just std::move it around. Put most of the driver back the way it was, with
small changes to clarify ownership.
Swift SVN r31811
inside a swift ast section in an object file so it can be passed to the
linker. The driver automatically wraps merged swiftmodules iff the target
is ELF.
rdar://problem/22407666
Swift SVN r31641
The "Tool" abstraction wasn't buying us enough to deserve the added
complexity. Now a ToolChain turns Actions into Jobs, and every helper
tool is searched for relative to Swift first. Much simpler.
Swift SVN r31563
Dependents of modified files are no longer rebuilt by default, only if it turns
out that file's interface has changed. There is a flag
-driver-always-rebuild-dependents to override this, but we expect it to only be
used for testing. (Most of the existing dependency tests pick up this option;
the two new tests have "interface-hash" in the name.)
This is the second half of ChrisW's work on interface hashing.
rdar://problem/15352929
Swift SVN r30478
This was just a wrapper around SmallVector that optionally owned the Job pointers
in it. Now that all Jobs are owned by the Compilation, we don't have to worry
about this any more.
No functionality change.
Swift SVN r29668
Previously, we would process all of a job's dependencies separately before
even scheduling it, and we wouldn't interleave dependencies from different
jobs. This meant (a) more overhead than necessary, and more importantly
(b) -embed-bitcode builds weren't being parallelized.
rdar://problem/21129029
Swift SVN r29665
...not if it's newer than its output .o file. This handles cases where the
object file is generated too quickly (rdar://problem/19404140) or when you
revert to a previous version of the file, mtime intact (rdar://problem/19720146).
There's a lot of test churn here; the only real new test is the backwards
mtime update in one-way.swift.
Swift SVN r29584
Together with -wmo it enables multi-threaded compilation.
I didn't want to reuse the -j option for this, because -num-threads (even if n == 1) does change the generated code.
For details see commit message of r25930.
Swift SVN r26258
With -embed-bitcode, we will invoke swift twice, once to generate the bitcode
file, the second time to perform code generation on the bitcode file.
For now, -embed-bitcode causes -incremental builds to not be incremental,
because of potential issues of mixing the two.
rdar://19048891
Swift SVN r25559
These aren't inherently incompatible, but today it would do nothing useful,
and using both flags together causes problems (see previous commit).
rdar://problem/19669432
Swift SVN r25389
Also, normalize the target triple up front, so that we're never dealing
with non-normalized triples in the driver unless explicitly asking for
the original user option.
rdar://problem/18065292
Swift SVN r24563
On gnu libc++ std::find (used on this iterator in
DependencyGraphTests.cpp:268) needs iterator traits to be properly
defined. This defines them for this iterator so it compiles
correctly.
Swift SVN r24478
If certain command-line arguments change, the results of the last
compilation aren't reusable, i.e. we can't do an incremental build.
Do a full rebuild when we detect that this happens.
(Which command-line options? Conservatively assume all of them, /except/
those with the new DoesNotAffectIncrementalBuild flag in Options.td.)
Swift SVN r24385
This is mostly just a matter of not throwing away mtimes we were already
looking up. We can compare these values to the mtimes of cross-module
dependencies to find out what's been updated.
Part of rdar://problem/19270920
Swift SVN r24336
We don't actually check them yet, but this fits them into the same dependency
structure as intra-module dependencies.
Part of rdar://problem/19270920
Swift SVN r24335
of 'bin/swift-update' with the related frontend options.
'swift-update' will be the tool for producing diffs to update swift code to the
latest version.
Swift SVN r24287
r23968 wrote out a record of which source files were included in a build,
and whether they were succesfully compiled or not...and if not, whether
they were out of date because of a cascading or non-cascading dependency.
This commit uses that information to decide what files might need to be
rebuilt even if a particular input doesn't change and doesn't appear to
have any changed dependencies. The two interesting cases are:
- A file was going to be built last time, but the build was halted
because of an error. Build it this time.
- One of the files was removed and thus we've lost a source of dependency
information; rebuild everything!
rdar://problem/19270980
Swift SVN r24018
"private" is a very overloaded term already. "Cascading" instead of
"non-private" is a bit more clear about what will happen with this sort
of lookup.
No functionality change. There are some double negatives I plan to clean
up in the next commit, but this one was supposed to be very mechanical.
Swift SVN r23969
This is important because we might get part-way through the full
compilation, overwriting swiftdeps files as we go, and then encounter an
error. We don't want to lose information about any decls that have been
removed since the previous compile, so we propagate forward the information
we already have by saving it to a "build record" file.
More simply, this is necessary to track when a file is removed from a target.
The next commit will handle reading in this file at the start of a build.
Swift SVN r23968
Specifically, we care about the case where a job is run because of a private
dependency, and then a non-private dependency turns out to be dirty. In
this case, we still need to make sure to build all downstream files.
With this the driver support for private dependencies should be complete
and correct.
Swift SVN r23853
- Add flags to dependency entries in DependencyGraph.
- Don't traverse past private dependencies in markTransitive.
- Only mark dependent jobs after a build if the build was triggered
(a) explicitly (because the file is out of date), or
(b) because of a non-private dependency.
This still isn't fully correct because of new non-private dependencies
discovered /after/ building an individual file, but it's on the way there.
Solving that problem will require tracking which dependencies have already
been marked dirty (next commit).
Swift SVN r23852
- Give loadWithPath an enum result that includes "NeedsRebuilding".
This will be returned when a new dependency is discovered that
retroactively affects the graph.
- Don't clear the "provides" set for a node when it gets reloaded;
just append to it. This lets us avoid calling markTransitive twice.
- Use proper types for "depends" and "provides" entries instead of std::pair.
- Use swift::OptionSet instead of a manual bitmask.
- Use separate "depends" and "provides" callbacks when parsing dependency
files.
No expected functionality change.
Swift SVN r23851
Add -whole-module-optimization option as synonym of
-force-single-frontend-invocation (for now). Add support for
-output-file-map when using -whole-module-optimization with multiple
input files -- the key for the single output file's map is the empty string.
<rdar://problem/18603795>
Swift SVN r23625
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
...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
