Doing so may have made sense back then, but at this point we should
default to the one in the toolchain. When building with asserts, the
just-built dsymutil will run the DWARF verifier which is slow and not
really desirable in this context.
This drops the dependency on the system libxml2 from the tools shipped
in the toolchain bundle. libxml2 is disabled entirely for the LLVM/lld
build, which uses it for processing the Windows manifest files. LLDB is
changed to link against the static libxml2 built for the FoundationXML
library. This is technically incorrect since the runtime may be
cross-compiled for a different platform than what the toolchain is built
to run on, but build-script is already mixing toolchain and runtime
content in inconsistent ways, so this is no worse off than we are
already.
libxml2 is updated pretty frequently in inconsistent ways, resulting in
failures to launch due to version incompatibilities.
- CompatibilityVersionDisplayString isn't required and it's misleading
to write Xcode 8 here, which is far below the actual compatibility
- ENABLE_BITCODE is now ignored by Swift Build
- SWIFT_DISABLE_REQUIRED_ARCLITE is now ignored by Swift Build
- SWIFT_LINK_OBJC_RUNTIME doesn't need to be set as it's already set to
an appropriate per-platform default
This is useful when building cross-compilation toolchains where you want
the stdlib and corelibs cross-compiled but don't want the Swift compiler
cross-compiled too with `--cross-compile-hosts`.
The 64-bit ARM architecture spelling on FreeBSD is aarch64, not arm64.
This results in a build failure about a missing
`freebsd/arm64/swiftrt.o` while building the runtimes.
If you use SwiftStdlibCurrentOS availability, you will be able to
use new types and functions from within the implementation. This
works by, when appropriate, building with the CurrentOS availability
set to the current deployment target.
rdar://150944675
LLVM-21 plans to remove the legacy method for building compiler-rt
in the same invocation as LLVM using `LLVM_ENABLED_PROJECTS` and
`LLVM_BUILD_EXTERNAL_COMPILER_RT`.
Support the new way of building compiler-rt with a new build-script
opt-in flag `--llvm-build-compiler-rt-with-use-runtimes` --
this will allow a staged introduction, and will ensure we can revert
back to the old behaviour temporarily in case of unforeseen regression.
Since this flag is meant to be short lived, in an attempt to keep the
logic simple we are gating on it only the
CMake cache entries that strictly control the compilation mode, all the
other entries used for configuring are added in both modes.
Take this chance to remove some stale code from `build-script-impl`, and
move some code in the generic CMake product to the LLVM one.
Addresses rdar://147505298
To work-around #80059, we need to stop return address signing and
opt-out of BTCFI enforcement via enabling a platform linker option.
We don't want to completely undo the BTCFI work in the rare case that
we later figure out how to properly address the above issue, or allow
users who might want to benefit from BTCFI enforcement and won't use
Concurrency. To do this, condition the existing BTCFI flag enforcement
into a configuration option that defaults to off for now.
Because the new swift-driver needs to "know" whether the frontend is
configured to opt-out or not, and since the new driver communicates with
the frontend via the target info JSON to begin with, we add a field
that emits the build flavor to signal the right behavior.
WASI with Embedded Swift provides WASI-libc and libc++ headers necessary to build the `_Concurrency` module for Wasm. We now add `wasm32-unknown-wasip1-wasm` triple to `EMBEDDED_STDLIB_TARGET_TRIPLES` when `SWIFT_WASI_SYSROOT_PATH` is set, which builds the necessary stdlib slice.
---------
Co-authored-by: Yuta Saito <kateinoigakukun@gmail.com>
This was quite brittle and has now been superseded
by swift-xcodegen. Remove the CMake/build-script
logic for it, leaving the option behind to inform
users to switch to using xcodegen instead.
BTI enforcement is mandatory, which means if PAC and BTI instructions
are not emitted, then the compiled binary gets killed with SIGILL. The
platform default compiler achieves enabling PAC and BTI by embedding the
relevant enabled Clang compilation option flags into the local platform
toolchain, which affects C/C++ code generation.
For Swift however, to achieve the same effect, we would need to add the
relevant LLVM module flags in the IRGen process. But, since Swift uses
the Clang code generator when doing this, using the same option flag
approach will work here as well, and is probably preferable to
introducing operating system-dependent logic to the ClangImporter, for
example.
Finally, the stdlib needs to be built with PACBTI as well, since the
stdlib's global constructors get run when a compiled binary does. Since
the Swift build uses the just-built Clang for the stdlib, just embed the
necessary options into `CMAKE_C_FLAGS` and `CMAKE_CXX_FLAGS` via
`build-script-impl`. This will be redundant with the host compiler, but
at least it will be thorough.
* Reapply '[BuildSystem] Stop building for i386-watch-simulator (#77692)'
* [BuildSystem] Stop building for i386-watch-simulator
In Xcode16 it is not supported.
This initially broke client projects who were still building the legacy
architecture but now that's resolved.
* Make pointer bounds non-experimental
* Rename @PointerBounds to @_SwiftifyImport
* Rename filenames containing PointerBounds
* Add _PointerParam exception to stdlib ABI test
* Add _PointerParam to stdlib API changes
* Rename _PointerParam to _SwiftifyInfo
* Revert "[Build] Fix swift_build_support tests."
This reverts commit fc2d1b3b23.
* Revert "[BuildSystem] Stop building for i386-watch-simulator (#77692)"
This reverts commit 1ab968d2b6.
This change can't be made without other issues fixed downstream first.
However, to do this, we end up changing how amd64 is supported too.
Previously, I had tried to keep some meaningful separation between
platform spelling and LLVM spelling, but this is becoming more difficult
to meaningfully maintain.
Target specifications are trivially converted LLVM triples, and the
module files are looked up by LLVM triples. We can make sure that the
targets align, but then the Glibc to SwiftGlibc import breaks. That could
also be addressed, but then we get to a point where the targets set up
by build-script and referenced by cmake begin to misalign. There are
references in build-script-impl for a potential renaming site, but it's
not quite enough.
It's far simpler to give up and rename to LLVM spellings right at the
beginning. This does mean that this commit is less constrained to just
adding the necessary parts to enable arm64, but it should mean less
headaches overall from differing architecture spellings.
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>
While the swift compiler in Xcode links against tbd files in the sdk
that contain an armv7k slice, the open source swift toolchain links
against the stdlib dylb that is in the toolchain itself. This means that
we cannot drop support for armv7k support in the stdlib dylib without
losing support for building armv7k when back deploying to older watch
targets. For now, roll back the recent deployment target bump from 9.0
to 6.0 so that we keep armv7k and i386 simulator.
rdar://135560598
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.
Conflicts:
- `test/Interop/Cxx/class/method/methods-this-and-indirect-return-irgen-itanium.swift`
previously fixed on rebranch, now fixed on main (slightly differently).
Don't use the just-built clang on macOS. macOS does this more "right"
than the Linux build. Linux will sometimes use the just-built
Swift-driver with the just-built clang, but sometimes would use the
system clang instead. macOS uses the toolchain Swift-driver with the
toolchain clang. This is correct, but it means that if we force the
other clang, we'll get mismatched sanitizer runtimes so the ASAN bot
will fail.
