In most Linux distributions, installing a clang package other than the
default unversioned one will not install a symlink from /usr/bin/clang++
-> /usr/bin/clang++-N-M, which can break builds with a not so great
diagnostic (a separate problem).
"ld" and "clang++" are hard-coded in the link job actions, so provide a
frontend flag, -linker-path, as a customization point for these.
rdar://problem/23537079
Deploying to older OSs requires linking in a compatibility library called
"arclite", but this library isn't open source and won't be distributed with
our open source downloads. Fall back to the version in Xcode.
The next step is to remove the local symlink used in builds, but I wanted to
handle that separately.
rdar://problem/23421436
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
Previously we treated this the same as the inputs to the linker, but this
was problematic for a few reasons:
- Backend jobs don't produce
- .o inputs never produce .swiftmodule files (obviously).
So now we:
- explicitly track what can produce a swiftmodule
- don't run module merging if there's nothing to merge
- allow linking without a swiftmodule even under -g
Which gets us closer to being able to run the entire test suite with -g.
rdar://problem/22332569
Swift SVN r31376
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
