The last attempted fix relied on the assumption that lit was emulating shell
glob-expansion semantics, which it turns out it does not: lit looks at any 'cd'
command on a RUN line and then applies the specified directory as an absolute
prefix when resolving any subsequent non-absolute globs on the command line.
I.e. it will interpret the second line of:
RUN: touch /tmp/foo{1,2,3}.swift
RUN: cd /tmp && echo foo*.swift
as
RUN: cd /tmp && echo /tmp/foo1.swift /tmp/foo2.swift /tmp/foo3.swift
whereas sh interprets it as (and I wrote the last attempt relying on):
RUN: cd /tmp && echo foo1.swift foo2.swift foo3.swift
This new attempt therefore bypasses lit entirely and just delegates to sh.
While it might not be the most tasteful choice, it does what we want and in the
process lets us use loops to construct our testcase.
Turns out it's needed for normal builtins that can appear in inlinable
functions, including Objective-C's @available. Clang always links it
unconditionally, so so should Swift.
Note that this does mean you have to build compiler_rt to get a
successful test run on Apple platforms. That was always true if you
wanted the sanitizer tests to work, though.
rdar://problem/41911599
I can't see how we'd ever get this wrong at this point, but way back
in the early days of incremental builds we apparently managed to.
Adding a test just to close this out.
rdar://problem/23148987
Otherwise we get into a situation like this:
1. Change made to the interface of file A.swift that also causes an
error in A.swift.
2. Fixing the error in A.swift does not affect A.swift's interface.
3. File B.swift that depends on A.swift is not rebuilt, since the most
recent change to A.swift did not change its interface.
To fix this, mark downstream files as needing to be rebuilt even when
a compilation job fails with errors. Additionally, attempt to be extra
conservative when there's a crash.
rdar://problem/25405605
Removing an abstraction boundary also allowed me to fix a bug where we
could not run long tests in optimized mode, which prevented us from
being able to mark executable tests as long.
It turns out the problem was with the full length of the argument list
in characters (bytes), not just the /number/ of arguments. Defeat this
by using paths relative to the temporary directory we're using.
rdar://problem/25617239, hopefully for the last time.
With this, we're out of the business of passing large numbers of input
files on the command line to the frontend, which means we no longer
overflow argv with a mere 1100 input files under whole-module optimization.
In order to make sure this doesn't happen again, I'd like to also get
this working for
- swiftmodule inputs to the merge-module build phase
- /output/ files for multithreading single-frontend builds (WMO)
- object file inputs to the linker on OS X (response files for binutils
ld have different quoting rules)
Part 3 of https://bugs.swift.org/browse/SR-280.
