This reverts commit a67a0436f7, reversing
changes made to 9965df76d0.
This commit or the earlier commit this commit is based on (#40531) broke the
incremental bot.
- Checkout apple/swift-experimental-string-processing using a tag.
- Build `_MatchingEngine` as part of libswift (`ExperimentalRegex`) using sources from the package.
- Parse regex literals using the parser from `_MatchingEngine`.
- Build both `_MatchingEngine` and `_StringProcessing` as part of core libs using sources from the package.
- Use `Regex<DynamicCaptures>` as the default regex type until we finalize apple/swift-experimental-string-processing#68.
The latest CMake on Windows doesn't add `_CRT_USE_BUILTIN_OFFSETOF`
flag after we swap the compiler to clang-cl for targets like SourceKit. Also
`_add_host_variant_c_compile_flags` doesn't do so, because compiler
identification still points to MSVC compiler.
`_CRT_USE_BUILTIN_OFFSETOF` flag is necessary for `offsetof` calls to be
accepted as an integral constant expression.
This patch adjusts compiler identification on compiler swap and also
addresses some configuration issues related to clang-cl.
Currently, when having both ASan and UBSan enabled, the compiler is
passed "-sanitize=address -sanitize=undefined" which results in error:
invalid value 'address -sanitize=undefined' in '-sanitize='. Pass the
two flags separately to fix the issue.
Use the include search path for the header search rather than
constructing the path using relative paths. This is important for
getting the interop to work properly as well.
The latest Long Term Support NDK finally removed binutils, including the bfd/gold
linkers and libgcc. This simplifies our Android support, including making lld the
default linker for Android. Disable three reflection tests that now fail, likely
related to issues with swift-reflection-dump and switching to lld.
When building with unified builds, `CMAKE_SOURCE_DIR` is not the Swift
repository. Use the locally defined `SWIFT_SOURCE_DIR` variable to
reference the root of the Swift repository. Because libswift uses
`project` in the CMakeLists, we cannot use `PROJECT_SOURCE_DIR` here.
Fixes a linux build error.
It doesn’t make sense to let add HAS_LIBSWIFT to add_swift_host_library(). This was added to work around a linker bug (d22b348adb). Instead do the workaround in libSwiftScan/CMakeLists.txt.
Don't build the swiftCore module files in the bootstrapping phases. Instead use the module files in the SDK.
This reduces the build time overhead from 3min -> 30seconds.
* fix a typo which prevented linking the right bootstrapping libs
* build swiftDarwin for bootstrapping
* disable COW checks if built with bootstrapping-with-hostlibs
The latest Long Term Support NDK finally removed binutils, including the bfd/gold
linkers and libgcc. This simplifies our Android support, including making lld the
default linker for Android. Disable three reflection tests that now fail, likely
related to issues with swift-reflection-dump and switching to lld.
Also, add the libatomic dependency for Android armv7, just as on linux.
Adding build modes for libswift: off, hosttools, bootstrapping, bootstrapping-with-hostlibs
The two bootstrapping modes are new. For details see libswift/README.md
Using `support` llvm component ends up adding `-Xlinker /path/to/lib/libLLVMDemangle.a`
to `LINK_FLAGS` but `libLLVMDemangle.a` is not added as an input to the linking ninja statement.
As a workaround, in order to setup precise inputs for the ninja link statement, include `demangle` component
whenever `support` is mentioned.
This ensures that we pick up libraries from the toolchain before picking up
libraries from the SDK we are using. Normally it would not matter the order that
we add these -L files since the contents of the SDK and toolchain are
disjoint. Once we begin performing stage2 swift builds though, we no longer have
this property since we pass in the stage1's installed libraries as the SDK
directory and we have not split the two sets of libraries yet. The end result is
that if we have the -L in the previous order, we will pick up just built
compatibility libraries before we pick up the actual compatibility libraries
from the actual toolchain we are using to compile. This results in compilation
breakage.
The mangler fuzzer and reflection fuzzer build was broken, both by a problem in
the CMake scripts and also because of changes that have happened in other parts
of the code.
After talking with compnerd, because we're passing this directly to the
swift driver, we shouldn't have to do anything weird with the flags and
it should "just work". I'm frustrated enough with Windows that I'm just
going to go with that and go to bed. If I broke something, I'm sorry. I
tried as far as my sanity would allow.
This patch fixes the part of the build system where we aren't passing
the sanitizer flags to swift, so the linker isn't linking against the
sanitizer libraries.
* add the (still empty) libswift package
* add build support for libswift in CMake
* add libswift to swift-frontend and sil-opt
The build can be controlled with the LIBSWIFT_BUILD_MODE cmake variable: by default it’s “DISABLE”, which means that libswift is not built. If it’s “HOSTTOOLS”, libswift is built with a pre-installed toolchain on the host system.
This is just cruft that remained from the time when swift's host/target used the
same cmake code. Host tools do not statically link against just built artifacts.
There are three things going on here (note all on Darwin):
1. If one compiles a swift static library and links the static library into a
cxx executable, the cxx executable will need the -L flags to find the
appropriate libraries in the SDK/toolchain.
2. I fixed an rpath issue where due to old code I didn't understand/propagated
forward, we were setting the rpath to be the -L directory in the appropriate
SDK. After reasoning about this a little bit I realized that this was code
that was actually intended to be used for target libraries (for which the
given rpath would be correct). On the host side though on Darwin, we want to
use the rpath for the standard stabilized stdlib on the system.
3. I added Build System Unittests to ensure that this keeps on working. I also
added test cases that I should have added before. I just had never thought
about how to test this and I realized this method would work and would
prevent regressions while I am waiting for a new swiftc with driver fixes to
land.
Before a8ae9525aa, we could not do this since we
would fail to link since we didn't pass to clang the path to the toolchain dir
when the compatibility libraries live.
I already did this for executables. The reason why we must do this is that right
now there are bugs in cmake's swift support that makes it so that one can not
use swiftc to link targets with mixed c/c++/swift content even if the swift
content is indirectly added via linking. To work around this we must also ensure
that all libraries with mixed c/c++/swift objects link using clang. As an
additional side-effect of this, we must pass to the clang linker -L flags that
swiftc would normally provide for the linker. The two cases where I needed to do
this were:
1. -L path for the compatibility libraries. This path points into the toolchain
where these live. This is important since otherwise we will fail to link given
the minimum deployment target that swift (both host/stdlib) target today (10.9).
2. -L path to the SDK. This path points to the SDKs lib/swift/${HOST_PLATFORM}
for swiftCore and friends.
That being said, we still want people to be able to link pure swift libraries
using swiftc, so we introduce an option called PURE_SWIFT to add_host_library
that preserves this and is used to also set
IGNORE_LLVM_UPDATE_COMPILE_FLAGS (which arguably should have been called
PURE_SWIFT).
