When running the tests with a toolchain built with the "early swift
driver", we would incorrectly process the command line, losing the empty
string argument to `-sdk` which would then incorrectly process the
remainder of the command line. This allows most of the remaining tests
to pass with the early swift driver on Windows (assuming that the paths
are adjusted properly).
The toolchain was introduced in 710816d3e0
but was not used. Test cases now use fake resource dir to lookup
static-executable-args.lnk file, which is required by the toolchain but
is not present when not building stdlib for WASI.
Rather than computing an absolute path relative to Swift's resource
directory, use the compiler driver to locate the profiling runtime
relative to the C/C++ compiler's resource directory. This ensures that
we correctly locate the runtime. Additionally, because clang adds the
clang resource directory to the library search path, we do not need to
compute the path and can rely on the linker locating the runtime via the
library search path. This simplifies the handling for the profile
runtime linking on Windows.
Out of abundant paranoia, place the library link request after the
forced symbol inclusion as a GC root to ensure that `/opt:ref` will not
accidentally dead strip the symbol and force a reload of the library.
The Windows linker does not support `-u`. Furthermore, the compiler
driver does not forward the `-u` option to the linker. We correctly use
the `/include:` option from the linker. This should ensure that the
symbol is preserved even with `/opt:ref`. This spelling should be
compatible with both lld and link, which should provide sufficient
portability.
Take the opportunity to make it more obvious that the two parameters are
creating a pair that will be concatenated by using a braced initializer.
See
https://docs.microsoft.com/en-us/cpp/build/reference/include-force-symbol-references?view=msvc-160
for more details on the option.
The *-simulator target triples have been used consistently in tools for
several years to indicate simulator targets. Stop inferring the
simulator part, rdar://problem/35810403.
The *-simulator target triples have been used consistently in tools for
several years to indicate simulator targets. Stop inferring the
simulator part, rdar://problem/35810403.
Use `clang` rather than `clang++` as the linker driver. This ensures
that we do not force a C++ runtime on the general code. This is fine
for now as C++ interop is not yet available for Swift. This prevents
the accidental mix-and-match of various C++ runtimes. This can cause
problems on platforms like android where `libstdc++` is an unsupported
runtime but is generally the default for Linux platforms.
This option tells the compiler where to find a profdata file. The
information in this file enables PGO. For more information about the PGO
infrastructure, look for the -profile-generate option and for the
llvm-profdata tool [1].
[1] http://llvm.org/docs/CommandGuide/llvm-profdata.html
(1) We no longer put the Clang version string in our copy of or symlink to
Clang's resource directory.
(2) Newer Clang builds now generate a separate library for the Apple OS
simulators, instead of a fat binary.
We still need a proper end-to-end test for this, but that depends on
building compiler-rt with Swift, which isn't a standard config yet.
- Add frontend and standard library build support for tvOS.
- Add frontend support for watchOS.
watchOS standard library builds are still disabled during SDK bring-up.
To build for TVOS, specify --tvos to build-script.
To build for watchOS, specify --watchos to build-script (not yet supported).
This patch does not include turning on full tests for TVOS or watchOS, and
will be included in a follow-up patch.
Swift SVN r26278
This adds the -profile-generate flag, which enables LLVM's
instrumentation based profiling. It implements the instrumentation
for basic control flow, such as if statements, loops, and closures.
Swift SVN r25155
