The existing code was only recording a change in the /last/ dependency as needing
to rebuild the file. This could have caused things not to get rebuilt when they
should have.
In practice, a number of things have to coincide for this to cause problems:
- A dependency (let's say a type) has to be considered "modified" in this build.
- Some other file has to get rebuilt that didn't previously depend on the type,
or only depended on it in a non-cascading way (e.g. it's only used in function
bodies).
- The file had to not be rebuilt because of any cascading dependencies (or
because it itself changed).
- The file has to now depend on the type in a cascading way, so that downstream
files need to be rebuilt when they didn't before.
Noticed by inspection while fixing the previous issue.
This only shows up when there's a present-but-empty sequence node in
a swiftdeps file. The compiler never generates this, but it's in some of
the tests. I'm not sure why ASan didn't catch this.
This should fix the failures some people have been seeing with
test/Driver/Dependencies/private-after.swift, rdar://problem/23382722.
...when interpreting. Otherwise, the script may depend on library X, which
depends on library Y, where library Y is a standard Swift library, located
in lib/swift/$PLATFORM/.
Finishes rdar://problem/23588774
Implementing this for the general case either requires duplicating the
existing environment, or modifying TaskQueue to support "extra environment"
settings. Since we don't actually have any use cases for this yet, I'm
leaving it unimplemented for now.
Rest of rdar://problem/23588774
That's DYLD_LIBRARY_PATH on OS X and LD_LIBRARY_PATH on Linux for -L,
and DYLD_FRAMEWORK_PATH on OS X for -F.
Note that this commit doesn't actually include the setenv calls yet, so an
end-to-end test is coming in the next commit.
Part of rdar://problem/23588774
This is groundwork for setting [DY]LD_LIBRARY_PATH ahead of time when
invoking the interpreter, which is rdar://problem/23588774. The next
commit will set up the appropriate variable and use -driver-print-jobs
to test it; the following commit will apply the environment variable
when running a job.
This makes it easier to make interpreter modes behave differently from
compilation modes. Obviously that's a trade-off, since the two modes also
share plenty, but given how few of the existing CompileJobAction checks had
to be modified for the new InterpretJobAction, I think this is the right
way to go.
Groundwork for setting [DY]LD_LIBRARY_PATH ahead of time when invoking the
interpreter, which is rdar://problem/23588774.
This reverts commit 58cfa27eb5.
We require at least clang-3.6 for C++14 build support but
Ubuntu 14.04's clang-3.6 package does not lay down the symlink
/usr/bin/clang++ -> /usr/bin/clang++-3.6. We will require a
clang++ alternatives entry or symlink when building for these
systems (see README.md).
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
