Ideally this would also update the `--version` output to be overridden
by `SWIFT_TOOLCHAIN_VERSION`, but unfortunately various tools rely on
the current format (eg. swift-build).
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
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.
The CMake compiler checks depend on StringProcessing being implemented.
The old build system may not have rebuilt the module, which will cause
the compiler check to fail. Disable the CMake compiler verification.
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>
Adding `SWIFT_ENABLE_SWIFT_IN_SWIFT` option to enable or disable the
parts of Swift that require a Swift compiler to build. This is meant for
bootstrapping compilers on new platforms and is not guaranteed to result
in a compiler that will pass the test suite.
This option is on by default so that folks won't forget.
If the option is off, the resulting compiler does not include the Swift
optimizer sources in SwiftCompilerSources nor does the resulting
compiler have swift macro support.
This patch adds initial support for Emscripten SDK alongside the existing
support for WASI SDK. This is a first step towards building a part of
Swift compiler for Emscripten target (which will be used to build LLDB
with Swift to WebAssembly target).
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.
Pass the minimum deployment target into the builds when appropriate.
Fixes the clang warning about mismatched minimum deployment targets
passed via flag and compiler target.
Move the backtracing code into a new Runtime module. This means renaming
the Swift Runtime's CMake target because otherwise there will be a name
clash.
rdar://124913332
For C/CXX targets, sanitizer options are set by 'CMAKE_{C|CXX}_FLAGS' in
HandleLLVMComfig.cmake. However for Swift targets, they are set for each
target. That caused some mismatch issues. Instead set them globally for
Swift targets too.
rdar://142516855
Fixed an issue in the convenience wrapper that resulted in building all
copies of the standard library for the default compiler architecture
instead of the desired architecture. To fix this, we pull the desired
target triple and deployment target from the existing variables and pass
that into the CMake invocation.
This will support configurations where ninja is not the search path,
and will avoid problems that can arise from the stdlib build detecting
and using a different generator.
Addresses rdar://142268599
* 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
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 patch causes the convenient flow to automatically populate the
sources into the new runtime directory layout. This is run at build-time
so that it repopulates on each build. Since the resync script uses
`COPY_IF_DIFFERENT`, only files that change in the main source directory
are copied over, so incremental builds should still work.
Fixed a small bug in the resync script to ensure that it creates the
subdirectories in the right places.
Setting `SWIFT_ENABLE_NEW_RUNTIME_BUILD` to `ON` will build and run the
new standard library build in addition to using the old build. This is
primarily for basic smoke testing at the moment. Once we're confident,
we can start running tests against the stdlib built with the new
build system.
The mechanism will build the stdlib for each of the same platforms that
the old build system would build for, but emitting a separate build
directory with a separate CMake invocation for each configuration.
This will use the just-built compiler if the compiler was not
cross-compiled. If the compiler were cross-compiled, it will use the
compiler from the toolchain that is known to work on the builder.
With newer llvm, importing 'llvm/include/llvm/ADT/DynamicAPInt.h' causes
an error:
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.39.33519\include\numeric:598:12: error: function '_Select_countr_zero_impl<unsigned long long, (lambda at C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.39.33519\include\numeric:598:55)>' with deduced return type cannot be used before it is defined
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.
Trying to run a debug build of the Swift compiler with a host Swift toolchain on Windows was failing with a linker error due to a mismatched `_ITERATOR_DEBUG_LEVEL` macro.
This avoids the linker error by disabling bounds-checked iterators on Windows. See the inline comment for details.
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
The Apple SDKs have been providing the Darwin overlay since macOS 10.14.4, iOS 12.2, et al. More recently the SDK version has diverged from the Swift version making them incompatible. Stop building the overlay from Swift. Once the SDK overlays aren't being built, the clang overlays need to be built in testing.
rdar://115192929
The Apple SDKs have been providing the Darwin overlay since macOS 10.14.4, iOS 12.2, et al. More recently the SDK version has diverged from the Swift version making them incompatible. Stop building the overlay from Swift. Once the SDK overlays aren't being built, the clang overlays need to be built in testing.
%target-swift-emit-pcm doesn't use the sdk, but %target-swift-frontend does, which will cause them to have a mismatch with "builtin headers belong to system modules, and _Builtin_ modules are ignored for cstdlib headers" aka LANGOPT(BuiltinHeadersInSystemModules) aka -fbuiltin-headers-in-system-modules.
rdar://115192929
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.
