On Windows, there are multiple variants of the C runtime that must be
explicitly specified and consistently used from the runtime to the
application. The new `-libc` option allows us to control the linking
phase by correctly embedding the requested library to be linked. It is
made into a required parameter on Windows and will add in the
appropriate flags for the imported C headers as well. This ensures that
the C library is not incorrectly linked.
This allows us to mark this flag as DoesNotAffectIncrementalBuild, so
that switching between a tty and non-tty doesn't cause full rebuilds
with swiftpm.
https://bugs.swift.org/browse/SR-7982
Previously, the TSan runtime only required libdispatch on Darwin, which
required no explicit linker flags, because libdispatch is always
provided by the system (libSystem).
Now, the TSan runtime also has a link-time dependency on libdispatch on
Linux, where libdispatch (and the blocks runtime) is just another
library. We therefore need to specify them as additonal linker options.
The signaled callback is treated more as a general crash handler clean
up wise. While it doesn't 100% line up, have Windows call the signaled
callback on exit codes considered to be errors.
To display stack traces from child processes, the driver combines stdout
and stderror together on Unix. This makes the Basic implementation also
do that.
This field is reverse-path-sorted, so the order depends on what
architecture we're compiling for. That's not what's being tested,
so just use a CHECK-DAG.
rdar://problem/48377454
Windows doesn't know what a shebang is, so it's unable to run tests that
use -driver-use-frontend-path with a script. This allows the script
interpreter to be run as the executable with the script as its first
argument. e.g. --driver-use-frontend-path "python;my-script.py"
This changes the Swift resource directory from looking like
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
x86_64/
Swift.swiftmodule
Swift.swiftdoc
Darwin.swiftmodule
Darwin.swiftdoc
to
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
Swift.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
Darwin.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
matching the layout we use for multi-architecture swiftmodules
everywhere else (particularly frameworks).
There's no change in this commit to how Linux swiftmodules are
packaged. There's been past interest in going the /opposite/ direction
for Linux, since there's not standard support for fat
(multi-architecture) .so libraries. Moving the .so search path /down/
to an architecture-specific directory on Linux would allow the same
resource directory to be used for both host-compiling and
cross-compiling.
rdar://problem/43545560
The Driver/linker-clang_rt test had some of its run lines with incorrect prefixes.
(For example, the prefix for the iOS tests was 'IOS' rather than 'CHECK-IOS'). The
effect is that the CHECK lines in the test weren't actually used and so little was
being tested.
The commits updates the --prefix arguments so that the CHECK lines are active.
This also updates the test to specify the current behavior: namely that the
compiler-rt path is in "/lib/swift/clang/lib/darwin/" rather than "/lib/clang/darwin/".
I've also updated one of the tvOS lines to use the "tvos" in the target rather than
"ios". I suspect that was typo that wasn't caught the test wasn't running.
Including the mangled names in anonymous context metadata can bloat
code size, and is not needed for normal runtime resolution. However,
it aids debugging, so have -g implies the emission of this extra
metadata, which is always optional.
Whoever touched this test last didn't know the rule for arguments
passed to the interpreter: if they're after the file to interpret,
they're treated as arguments to the script rather than the compiler.
This was a nice feature when people said "-swift-version 3.1"...
up until we got "-swift-version 4.2" as an actual valid version.
Just drop the special case.
https://bugs.swift.org/browse/SR-8850
Ensure that we use the interpreter explicitly when running the touch.py
script. This is important for platforms that do not support shebangs
for interpreter execution.
In the Darwin toolchain the linker is invoked directly, and compiler_rt
is used if it is found, but in Unix platforms, clang++ is invoked
instead, and the clang driver will invoke the linker. Howerver there was
no way of modifying this clang++ invocation, so there's no way of
providing `--rtlib=` and change the platform default (which is normally
libgcc). The only workaround is doing the work that the Swift driver is
doing "manually".
The change adds a new option (with help hidden, but we can change that)
to allow providing extra arguments to the clang++ invocation. The change
is done in the two places in the Unix and Windows toolchains that I
found the clang driver was being used.
Includes some simple tests.
For example, the first regex matched the following text incorrectly (the `-filelist` argument matched until the first open double-quote in `"BUILD_DIR/\$(CONFIGURATION)...`).
````
BUILD_DIR/Debug/bin/swift -frontend -c -filelist /var/folders/.../sources-098836 -primary-filelist /var/folders/.../primaryInputs-b8aa5a -supplementary-output-file-map /var/folders/.../supplementaryOutputs-b1a037 -target x86_64-apple-macosx10.9 -enable-objc-interop -module-cache-path "BUILD_DIR/\$(CONFIGURATION)\$(EFFECTIVE_PLATFORM_NAME)/swift-test-results/x86_64-apple-macosx10.9/clang-module-cache" -swift-version 4 -module-name main -output-filelist /var/folders/.../outputs-c97286
````
Also removes unused variables.
- Many tests got broken because of two things:
- AST dump now outputs to stdout, but many tests expected stderr. This was a straightforward fix.
- Many tests call swift with specific parameters; specifically, many call `swift frontend` directly. This makes them go through the compiler in unexpected ways, and specifically it makes them not have primary files, which breaks the new AST dump implementation. This commit adds the old implementation as a fallback for those cases, except it dumps to `stdout` to maintain some consistence.
Finally, the `/test/Driver/filelists.swift` failed for unknown reasons. It seems its output now had some lines out of order, and fixing the order made the test pass. However, as the reasons why it failed are unknown, this fix might not have been a good idea. Corrections are welcome.
This change allows the swift driver to link the ubsan runtime if
`-sanitize=undefined` is specified.
This is useful for sanitizing linked Objective-C code.
Most of the driver tests currently don't work on Windows, but these two were relatively fixable.
- Moved the dsym checks to actions-dsym and ignore that on windows
- alternatively match the full path of dsymutil, which on Windows is
given as "C:\....\dsymutil.exe" verify-debug-info ...
