and match the usage pattern employed by other LLVM projects.
For context about the underlying change see https://reviews.llvm.org/D117977
Addresses rdar://101396797
(cherry picked from #61769, commit 2763cc3911)
The SDK doesn't have the new compatibility library and the
crosscompile-with-hostlibs bootstrap configuration is failing.
This bootstrap configuration is the only one that does not fall back on
the host built compatibility libraries if it is not available in the
SDK.
When enabled, compile in support for round-trip testing the new
SwiftSyntax-provided Swift parser alongside the existing parser. Right
now, this means parsing every source file with the new parser and
ensuring that the resulting syntax tree can reproduce the input source
precisely. Over time, this is expected to grow.
Opt in to this behavior by passing the following to build-script:
build-script --early-swiftsyntax --extra-cmake-options=-DSWIFT_SWIFT_PARSER_MODE:STRING=ROUNDTRIP
Make libSyntax depend on swift-syntax: the new home for all
of this infrastructure. This greatly simplifies the addition and
amending of syntax nodes as only the swift-syntax paired with a
swift checkout will need to be changed. This is in contrast to
the existing build flow where a paired PR to both repos must be
made to change anything here.
Note that a paired PR may still be required if the legacy parser
needs to be adjusted in response to syntax nodes changing, but I
anticipate this to be a much more infrequent event now that
the C++ end of libSyntax is deprecated.
Refactor the logic so to have a single target to reference the
compatibility libraries for the host, and use that when needed.
The main driver for this change is supporting the cross-compilation of
x86-64 on Apple Silicon.
Supports rdar://90307965
These are better done via the SwiftConfigureSDK mechanism rather than
how I was doing them previously. Additionally, I've changed the way
that the swift-threading-package option works. In addition to
specifying just a single package name, you can specify it as a CMake
list (i.e. separate by semicolons) of colon-separated `sdk:package`
pairs, e.g. `osx:darwin;linux:pthreads`. You can also override it
for all SDKs and then specify for a given SDK; specifications for a
particular SDK take precedence over the global override. For instance
`pthreads;osx:darwin` says to use `pthreads` except on the OS X SDK
where we should use `darwin`.
Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
To use _RegexParser from SwiftSyntax.
* Create 'libswiftCompilerModules_SwiftSyntax.a' which is a subset of
'libswiftCompilerModules.a'
* Link 'lib_InternalSwiftSyntaxParser' to
'libswiftCompilerModules_SwiftSyntax.a'
* Factor out swift runtime linking logic in CMake so that dynamic
libraries can link to Swift runtime, in addition to executables
* Link 'lib_InternalSwiftSyntaxParser' to swift runtime
Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
Since libstdc++ doesn't come with a Clang modulemap, Swift provides its own modulemap for libstdc++. This change makes the modulemap available while building SwiftCompilerSources.
Internal configurations targeting Darwin employ ThinLTO to
improve compiler performance, however using it on all executable
causes build time to increase with no matching benefit.
To reduce build times in such configurations, we allow some
ancillary targets to opt out of LLVM IR optimizations when linking
ThinLTO with ld64 (e.g. tools used for bootstrapping or debugging the
Swift compiler) -- this behaviour is opt in through a new flag
`--swift-tools-ld64-lto-codegen-only-for-supporting-targets`.
Addresses rdar://76702687
Previously we were setting `-arch` explicitly and unsetting
`CMAKE_OSX_ARCHITECTURES`; however this approach does not work when
building on Apple Silicon, since in there CMake 3.19+ enforces a default
value
(https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5291/diffs),
and this would result in the inability to compile code for x86_64.
This is a similar approach used for stdlib targets in #38415
Addresses rdar://88100025
We need an option to pass external host clang location in case
we can't use just-built clang, e.g. when we are building for
different target architecture.
Also, this adds target options for clang-cl, enabling us to
build for arm64 on Windows@amd64.
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.
