This allows the file to be easily included where needed (e.g.
`StandaloneOverlay.cmake`) and reduce the likelihood of miscompilation
due to missing sensible defaults.
As a start, focus on a handful of parameters that got added/modified in
recent PRs.
Addresses rdar://85978195
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.
Unfortunately using the convenient "bootstrapping0-all", etc. custom targets does not work.
For some reason it does not cause a dependent file (like libswift's SIL.o) being rebuilt when a depenency (like swift-frontend from the previous bootstrapping stage) changes.
Instead we have to list al library- and executable-targets explicitly.
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.
swiftDarwin and swiftOnoneSupport didn't depend on building the Swift core library.
This was a subtle bug, because the compiler just picked up the module from the SDK instead of the (still building) Swift module.
It only resulted in compiler errors if the SDK swiftinterface was too new to be parsable by the compiler.
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.
This is useful for restoring the Windows ARM64 port of the runtime.
This currently does not build due to issues in the module.map
definitions causing a build failure. However, adding the file enables
others to reproduce the build and help.
Do not attempt to use a cross-compiled compiler for a foreign target. This is not guaranteed to work (e.g. building for ARM on x64). This at least surfaces the error properly.
This adds a CMake cache for the Windows ARM64 toolchain. It is possible
to build and run the toolchain on ARM64, though we have not had regular
releases of the toolchain. This adds the cache used to generate the
toolchain in the hopes that it is useful for others and that we can soon
get more regular ARM64 toolchain builds.
The SwiftDriver searches `swift-frontend` based on `Bundle.main.executablePath` (which internally uses `CFGetProcessPath`). This search dir is resolved differently on macOS and Linux so swift-frontend can't be found on Linux, forcing the driver to fallback to using the host system toolchain instead of the just-built one.
* 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
