For compiling codes required for macro support, we now need swiftc
compiler in the build machine.
Unlike Darwin OSes, where swiftCore runtime is guaranteed to be present
in /usr/lib, Linux doesn't have ABI stability and the stdlib of the
build machine is not at the specific location. So the built compiler
cannot relies on the shared object in the toolchain.
These builds do not work outside of darwin currently. Rather than adding
the skip to all the necessary build presets, just disable in the product
instead.
This library served its purpose and has overstayed its welcome.
The library shipped in Xcode can't change again from the state it was
in, so changes to the sources here will not affect that library, which
is confusing. The library does not currently build due to changes in the
runtime headers, so it does not give meaningful signal to anything
anymore. If you need to test things in a backdeploy concurrency
environment, use the copy from the toolchain in Xcode as that will give
you a far clearer picture of what the code will actually be running with
than the state of the sources here did.
This solves deprecation warnings in build-script:
```
DeprecationWarning: 'pipes' is deprecated and slated for removal in Python 3.13
```
This change assumes that the minimum version
of Python3 is 3.3, which has `shlex.quote`.
Since our build bots currently use 3.6 as their
Python version, we can't yet use `shlex.join`
to further simplify some of the code using
quote.
This attribute can be attached to a noncopyable struct to specify that its
storage is raw, meaning the type definition is (with some limitations)
able to do as it pleases with the storage. This provides a basis for
implementing types for things like atomics, locks, and data structures
that use inline storage to store conditionally-initialized values.
The example in `test/Prototypes/UnfairLock.swift` demonstrates the use
of a raw layout type to wrap Darwin's `os_unfair_lock` APIs, allowing
a lock value to be stored inside of classes or other types without
needing a separate allocation, and using the borrow model to enforce
safe access to lock-guarded storage.
`test_cmark` is set by default to `True` because of the indirect way
we define it through `--skip-test-cmark` -- we want instead the user to
opt in into this explicitly, as CMark tests on their own have little
value when building as part of Swift.
Addresses rdar://112604393
tests: configure Wasm runtime selection in `lit.cfg`
Currently `wasmer` is hardcoded as a Wasm runtime for running tests. We should make this configurable to be able to select an arbitrary runtime.
Currently, when building LLVM/clang on Alpine Linux, CMake toolchain file specifies incorrect `<cpu_arch>-unknown-linux-musl` target, which makes the build immediately fail. Correct target that allows building on Alpine should be specified as `<cpu_arch>-alpine-linux-musl`, with `<cpu_arch>` replaced with respective CPU platform, e.g. `aarch64`.
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`,
etc. These conflict with expressions that used these names as unquoted
strings in positions where CMake accepts 'variable|string', for example:
- `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and
expands to 1, where it would previously coerce to a string.
- `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the
left-hand side expands twice.
In this patch, I looked for a number of patterns to fix up, sometimes a
little defensively:
- Quoted right-hand side of `STREQUAL` where I was confident it was
intended to be a string literal.
- Removed manual variable expansion on left-hand side of `STREQUAL`,
`MATCHES` and `IN_LIST` where I was confident it was unintended.
Fixes#65028.
Currently, when building LLVM/clang on Alpine Linux, CMake toolchain file specifies incorrect `<cpu_arch>-unknown-linux-musl` target, which makes the build immediately fail. Correct target that allows building on Alpine should be specified as `<cpu_arch>-alpine-linux-musl`, with `<cpu_arch>` replaced with respective CPU platform, e.g. `aarch64`.