This way they can be used from other projects, like LLDB. The downside
is we now have to make sure the header is included consistently in all
the places we care about, but I think in practice that won't be a problem,
especially not with tests.
rdar://problem/22240127
Swift SVN r31173
Normally we don't get here because the build record will be out of date,
but if we don't actually rebuild all the files we'll crash on the /next/
build.
Swift SVN r30889
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
Compute the hash of all interface tokens when parsing; write the
interface hash to the swiftdeps file, or if the -dump-interface-hash
option is passed to the frontend. This hash will be used in incremental
mode to determine whether a file's interface has changed, and therefore
whether dependent files need to be rebuilt in response to the change.
Committed on ChrisW's behalf while he gets his setup unborked.
rdar://problem/15352929
Swift SVN r30477
If file A extends a common type (say, Dictionary), but only adds new members,
other files using Dictionary don't need to be recompiled if they definitively
don't use those members. That should be working now.
Swift SVN r30286
- (depends|provides)-top-level for top-level names.
- (depends|provides)-nominal for access into nominal types.
- (depends|provides)-dynamic-lookup for @objc members available on AnyObject.
- depends-external for cross-module file-based dependencies.
No functionality change.
Swift SVN r30283
The parsing code should really be more forgiving anyway, but there's no reason
to even try to read the swiftdeps files if we're rebuilding everything anyway.
Swift SVN r30281
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
This is consistent with Clang, which rejects -mllvm options. All options
Clang /does/ accept should be covered by normal Swift flags.
rdar://problem/21245117
Swift SVN r29386
They mostly did (r28750 was incorrect about this) but we should be testing
real configurations. Now that the tests have been updated, remove this.
(Eventually we'll need to design incremental builds without an output file
map, so that they work with simpler build systems like Ninja.)
Swift SVN r28777
With both force-single-frontend-invocation and embed-bitcode, we create
CompileJobAction and BackendJobAction, similar to how we handle embed-bitcode
with StandarCompile.
This commit should only affect Bitcode mode.
rdar://20796819
Swift SVN r28129
and link it properly. This is needed to embed LLVM bitcode sections
in the standard library and overlays. The linker doesn't support
embedded bitcode and reexport flags (among others).
rdar://problem/20750099
Swift SVN r28052
With both emit-module and embed-bitcode, MergeModule will get the swiftmodule
inputs from CompileJobAction instead of BackendJobAction.
This commit should only affect Bitcode mode since it only touches how we handle
BackendJobAction which is used for Bitcode mode.
rdar://20678489
Swift SVN r27878
