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)
This is the start of the removal of the C++ implementation of libSyntax
in favor of the new Swift Parser and Swift Syntax libraries. Now that
the Swift Parser has switched the SwiftSyntaxParser library over to
being a thin wrapper around the Swift Parser, there is no longer any
reason we need to retain any libSyntax infrastructure in the swift
compiler.
As a first step, delete the infrastructure that builds
lib_InternalSwiftSyntaxParser and convert any scripts that mention
it to instead mention the static mirror libraries. The --swiftsyntax
build-script flag has been retained and will now just execute the
SwiftSyntax and Swift Parser builds with the just-built tools.
There were three different issues going on here, all of these were triggered by https://github.com/apple/swift/pull/61618 which stared including `AST/AnyFunctionRef.h` from the ASTBridging modulemap
- We did not find the clang include dirs because the unified build that build-tooling-libs is using does not import ClangConfig, setting `CLANG_INCLUDE_DIRS` in `swift_common_unified_build_config` fixed this problem.
- Some of the headers in `swift-ast-generated-headers` import generated headers from clang that might not have been created yet. Making `swift-ast-generated-headers` depend on the clang generated headers fixes this problem. This just lowers the dependency because `swiftAST` depends on `swift-ast-generated-headers`
- If a Swift compiler from Xcode is used, the SwiftShims don’t live next to the compiler but in the SDK. Adding the SDKs lib to the include paths fixes this problem
The function that adds runtime link flags overrides RPATH settings via
`BUILD_WITH_INSTALL_RPATH`. Stop doing that for unit tests, because they
depend on host libraries built into `lib` not `lib/swift/${platformname}`.
This replaces a number of `#include`-s like this:
```
#include "../../../stdlib/public/SwiftShims/Visibility.h"
```
with this:
```
#include "swift/shims/Visibility.h"
```
This is needed to allow SwiftCompilerSources to use C++ headers which include SwiftShims headers. Currently trying to do that results in errors:
```
swift/swift/include/swift/Demangling/../../../stdlib/public/SwiftShims/module.modulemap:1:8: error: redefinition of module 'SwiftShims'
module SwiftShims {
^
Builds.noindex/swift/swift/bootstrapping0/lib/swift/shims/module.modulemap:1:8: note: previously defined here
module SwiftShims {
^
```
This happens because the headers in both the source dir and the build dir refer to SwiftShims headers by relative path, and both the source root and the build root contain SwiftShims headers (which are equivalent, but since they are located in different dirs, Clang treats them as different modules).
This macro was previously substituted when generating `glibc.modulemap` file during the compiler build. Now Swift detects the location of Glibc dynamically and injects `glibc.modulemap` into it using LLVM VFS. The last usage of `GLIBC_INCLUDE_PATH` was removed in `78c0540b`.
This also removes `SWIFT_SDK_${sdk}_ARCH_${arch}_LIBC_INCLUDE_DIRECTORY` which doesn't have any usages left.
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
With a properly prepared sysroot and toolchain file, these changes permit
cross-compilation of Swift as well as LLVM, CMark, and Dispatch (picking,
as usual, apple/swift-corelibs-libdispatch#556) from a Linux host
generating OpenBSD binaries.
The toolchain file must be specified as an environment variable to
`build-script` and discussion on how to properly set up the sysroot and
toolchain file will be handled later.
Added a check that someone hasn't passed us an argument with too many
colons. Also renamed `find_threading_package` to `get_threading_package`
to better reflect what it does.
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
