* Add the signal number of the terminated task to the output of the driver on platforms for which the signal number is available. The new key in the parseable driver output is "signal".
* Add a test to verify that the signal number is emitted.
* Add documentation for the new "signal" key emitted in the parseable driver output.
https://bugs.swift.org/browse/SR-3175
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
Groups are required for Timers after SVN r286524. SVN r287369 requires that
timers have short names and long descriptions. Adjust the API usage
accordingly. Reorder some words to make some more sense as a description.
The Swift compiler uses files with an extension of ".swiftdeps" to store
information about cross-file dependencies. These files are read in at the
start of compilation to compute a dependency graph, and updated as compilation
proceeds. However, because these files are updated on every build, an
issue with dependency analysis is hard to reproduce—the inputs have been
lost.
Address this by renaming swiftdeps files that are about to be
overwritten, to '.swiftdeps~'. This preserves dependency information
from the most recent compilation (but no further back).
This flag switches the "effective language version" of the compiler,
at least to any version supported (as of this change: "3" or "3.0").
At the moment nothing uses it except the language version build
configuration statements (#if swift(...)) and various other places
that report, encode, or otherwise check version numbers.
In the future, it's intended as scaffolding for backwards compatibility.
Fixes SR-2582
Define compilation record (.swiftdeps) top-level keys, as well as string
identifiers used in compilation record files (like "!dirty" and "!private"), in
a single location. NFC.
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
Some modifications for the ms-extension option of the clang.exe in the Visual Studio 2015 development environment
This patch is only for swiftc.exe. I used the library set of Visual Studio 2015 Update 1 and recent version of swift-clang as the compiler. If you are using the real MSVC compiler, more patch might be required.
This is only the driver side of the work; the frontend doesn't understand
this new -output-filelist option yet. Next commit.
More https://bugs.swift.org/browse/SR-280.
This is simply a newline-separated list of files, matching the format
from Darwin ld's -filelist option.
Part 2 of https://bugs.swift.org/browse/SR-280.
Generate frontend commands with -filelist in them. This isn't actually
implemented yet, but we can start testing at this point.
Part 1 of https://bugs.swift.org/browse/SR-280.
Previously jobs had to grovel this information out of the raw argument
list, which dropped the types we had inferred on input files. This
makes things more consistent across the compiler, though arguably we
should be able to designate "primary" and "non-primary" inputs on a
per-action basis rather than resorting to "global" state.
Use this new information to stop passing object file inputs to the
Swift frontend, fixing rdar://problem/23213785.
The list wouldn't have to live on the Compilation, but I'm going to use
it to fix SR-280 / rdar://problem/23878192 as well.
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
