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`.
Allow Linux distributions to provide their own C++ flags to compile the
C++ overlay correctly. The default is kept the same for Ubuntu and
CentOS, but other distributions can provide other flags to use their own
distro GCC stdlibc++ or even libc++ if they choose.
This should not change the current compilation, but opens the door for
other maintainers to provide a different value that work on their
systems.
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
SWIFT_STDLIB_SINGLE_THREADED_RUNTIME is too much of a blunt instrument here.
It covers both the Concurrency runtime and the rest of the runtime, but we'd
like to be able to have e.g. a single-threaded Concurrency runtime while
the rest of the runtime is still thread safe (for instance).
So: rename it to SWIFT_STDLIB_SINGLE_THREADED_CONCURRENCY and make it just
control the Concurrency runtime, then add a SWIFT_STDLIB_THREADING_PACKAGE
setting at the CMake/build-script level, which defines
SWIFT_STDLIB_THREADING_xxx where xxx depends on the chosen threading package.
This is especially useful on systems where there may be a choice of threading
package that you could use.
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
SWIFT_STDLIB_SINGLE_THREADED_RUNTIME is too much of a blunt instrument here.
It covers both the Concurrency runtime and the rest of the runtime, but we'd
like to be able to have e.g. a single-threaded Concurrency runtime while
the rest of the runtime is still thread safe (for instance).
So: rename it to SWIFT_STDLIB_SINGLE_THREADED_CONCURRENCY and make it just
control the Concurrency runtime, then add a SWIFT_STDLIB_THREADING_PACKAGE
setting at the CMake/build-script level, which defines
SWIFT_STDLIB_THREADING_xxx where xxx depends on the chosen threading package.
This is especially useful on systems where there may be a choice of threading
package that you could use.
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.
Convert the NDK path to allow the native path to be used when
configuring the Swift runtime but use the CMake spelling when
performing the inner configure.
This separates it from `libSwiftScan` and allows us to build this library without building much of the rest of the compiler.
Also refactor `utils/build-parser-lib` into `utils/build-tooling-libs` which builds both SwiftSyntaxParser and SwiftStaticMirror.
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 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.
