Add @PointerBounds macro
@PointerBounds is a macro intended to be applied by ClangImporter when
importing functions with pointer parameters from C headers. By
leveraging C attributes we can get insight into bounds, esapability, and
(eventually) lifetimes of pointers, allowing us to map them to safe(r)
and more ergonomic types than UnsafePointer.
This initial macro implementation supports CountedBy and Sizedby, but
not yet EndedBy. It can generate function overloads with and without an
explicit count parameter, as well as with UnsafeBufferPointer or Span
(if marked nonescaping), and any of their combinations. It supports
nullable/optional pointers, and both mutable and immutable pointers.
It supports arbitrary count expressions. These are passed to the macro
as a string literal since any parameters referred to in the count
expression will not have been declared yet when parsing the macro.
It does not support indirect pointers or inout parameters. It supports
functions with return values, but returned pointers can not be bounds
checked yet.
Bounds checked pointers must be of type Unsafe[Mutable]Pointer[?]<T>
or Unsafe[Mutable]RawPointer[?]. Count expressions must conform to
the BinaryInteger protocol, and have an initializer with signature
"init(exactly: Int) -> T?" (or be of type Int).
rdar://137628612
---------
Co-authored-by: Doug Gregor <dgregor@apple.com>
This change allows build-script to be invoked with the following combination:
```
--llvm-targets-to-build=host --build-embedded-stdlib=false
```
When `--build-embedded-stdlib=false` is used, it's unnecessary to force-configure
additional compiler-rt targets. Further, when `--llvm-targets-to-build` is used,
the resulting llvm usually won't support the forced targets of armv6/armv7.
This ensures that log messages are printed as soon as a corresponding build step starts, instead of printing these messages in the end out of order.
For example, before for SwiftPM
```
--- Cleaning swiftpm ---
--- Building swiftpm ---
--- Running tests for swiftpm ---
--- Finished tests for swiftpm ---
--- Installing swiftpm ---
```
was printed at the end of the CI job log with no actual build phase output in between these markers. Now these build phase markers are printed in the correct order and one can infer which log messages were printed for each build phase.
This patch enables building `compiler-rt/lib/profile` for WebAssembly
targets. This is necessary to support `-fprofile-instr-generate` for
WebAssembly targets.
This change disables the use of llvm libunwind in libcxxabi, which is enabled by default in the rebranched scheme. (https://reviews.llvm.org/D150897) But the llvm libunwind is not supported in the WebAssembly target, so we need to disable it explicitly.
This is a preparation for the upcoming `rebranch` merge.
Instead of building SourceKit-LSP using SwiftPM's multi-arch xcbuild backend, build it for only one arch at a time and then run `lipo` to merge the two resulting binaries.
This should allow us to share build products between building installing and testing and also eliminates other quirks resulting from the xcbuild backend.
We have been using the host LLVM build directory to configure the Wasm
Swift stdlib. This has been working fine so far as the stdlib build is
configured with `CMAKE_SYSTEM_NAME` having host system name. However,
we fixed the stdlib build to use `WASI` as the system name properly in
the previous commit. This exposed the issue that the host LLVM build
directory is not suitable for configuring the stdlib build.
We didn't set the CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_PROCESSOR when
cross-compiling stdlib for WASI. This caused the build to fail on macOS
host machines as the build system was trying to build some overlays
assuming the target is macOS.
Additionally, add a default "SWIFT_HOST_VARIANT_SDK" for WASI target
even though we don't support it as a host system yet because it's
required anyway.
The static SDK overlay has been built implicitly for a long time, but
this is not the case anymore after 5bf2c937ab.
We need to build it explicitly now.
The Swift-Driver build here only requires a working swiftc, not
necessarily all of SPM. Relaxing the required tool check to accept
building the driver if there's a Swift compiler available.
During the toolchain build, when building the Swift standard library for
platforms other than macOS the `libclang_rt.a` needs to be copied out of the
host SDK. That wasn't happening for visionOS.
Resolves rdar://135023111.
These products are built with CMake. In incremental build environments,
these products don't detect compiler changes, so the artifacts aren't
rebuilt unless the source code of these projects are changed.
To workaround that, always clean them in build-script to ensure they are
rebuilt.
rdar://135021207
Bump the deployment target from macOS 10.13-aligned versions to macOS
13.0-aligned versions. This allows us to stop linking CoreFoundation
in the swift runtime, which was previously required for availability
checking. It also lets us align the deployment target on x86_64 with
arm64, which was 11.0. Finally, it is a prerequisite to being able to
build swift using the macOS 15 beta SDKs.
This change adds build support for swift-testing in the Wasm Swift SDK.
Unfortunately, we can't use the regular SwiftTesting build-script product
because Wasm build cannot use build-script's cross-compilation infrastructure
for now. So we build swift-testing in WasmSwiftSDK product and install it
to the SDK package.
Rather than make this change, swiftlang/sourcekit-lsp@37d003eb7 had the
`--no-clean` flag do nothing, which means the flag can't be used at all.
Instead, switch the flag to `--clean` in swiftlang/sourcekit-lsp#1558 and don't
invoke it by default.
Currently, when a command fails with this message
```
ERROR: command terminated with a non-zero exit status 1, aborting
```
it's unclear at all which exact command terminated, which makes it very hard to debug issues in the build script.
The stdlib build configuration for wasm is incompatible with the
embedded targets (e.g. `SWIFT_STDLIB_COMPACT_ABSOLUTE_FUNCTION_POINTER=TRUE`),
so we need to disable building the embedded stdlib
