* 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
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.
It was already supposed to be enabled, but I forgot to update the CMake when I
renamed the feature from ExtensionImportVisibility to MemberImportVisibility.
However, leave it disabled on the CxxStdlib module since the C++ standard
library's modularization varies a lot by platform, making it difficult to add
the right conditional imports.
Add a new bits/ header to the Android overlay, include runtime libraries that are
auto-extracted and listed many times to the list of libraries to be de-duplicated,
enable a C++ interop test that's working again, and update the doc with new
libraries that need to be available to run a simple executable.
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>
These modules import Darwin which is not in ossa. -enable-ossa-modules
results in a one-time recompilation of dependencies when they are not in ossa.
This is not compatible with Explicit Build Modules when the original invocation
did not have -enable-ossa-modules.
The existing CMake code for macCatalyst swiftmodule only handled the
shared case, and did not have the static pieces that non-macCatalyst
targets are doing.
Try to match as much as possible the non-macCatalyst variables and
structure and allow macCatalyst targets to support static Swift targets.
This is important for the `Cxx.swiftmodule` and `CxxStdlib.swiftmodule`,
since they are only static, and the previous code skipped creating those
files since https://github.com/swiftlang/swift/pull/74994
This fixes linker warnings that look like this:
```
ld: warning: object file (libswiftCompatibility56.a) was built for newer 'macOS' version (XYZ) than being linked (ABC)
```
These were caused by the compatibility binary being incorrectly built with a newer `-target` than desired: the CMake logic was overriding the requested minimum macOS deployment version (10.9) with a much newer macOS SDK version.
rdar://137565964
Annotate all of the `Unsafe*` types and `unsafe` functions in the standard
library (including concurrency, synchronization, etc.) as `@unsafe`. Add a
few tests to ensure that we detect uses of these types in clients that
have disabled unsafe code.
add_swift_target_library was missing pieces for passing sources and
flags to the static SDK build. As a result, the static SDK was missing
pieces (specifically Mutex).
Also adding the Musl import to the Linux Mutex implementation.
We need to make sure that we build swift-backtrace with a deployment target
newer than 10.14.4 in order that we get linked against
`/usr/lib/swift/libswiftCore.dylib` rather than using an `@rpath`-based
path.
If we fail to do that, dyld becomes confused and we end up crashing with
weird errors about missing method implementations on `Swift.__StringStorage`.
To make this work, add support for `DEPLOYMENT_VERSION_*` in the
`add_swift_target_executable()` CMake function. And since I spotted a bug
in it, fix the existing support in `add_swift_target_library()` while I'm
there.
rdar://132710670
The reverse-condfail workaround needs to be removed, and this is the
first step to allowing the stdlib to build with conditionally escapable
types.
resolves rdar://132453000
This means we will get build IDs in the tools and standard library,
which is useful for debugging (it lets us associate debug symbols with
the binaries later on, as well as allowing us to reliably identify
exactly which binary we are looking at).
rdar://116525111
... operator in `add_swift_target_library` and
`add_swift_target_executable`
This can be the case when building the stdlib for embedded on its own
(i.e. without the compiler or other platforms).
Addresses rdar://128819523
We need to make sure that we add the compatibility libraries as
dependencies for target executables, otherwise we can end up with
a race condition in the build where the build will fail if the
compatibility libraries haven't been built by the time e.g.
`swift-backtrace` is linked.
rdar://128197532
When SWIFT_BUILD_STATIC_STDLIB=ON, SWIFT_BUILD_DYNAMIC_STDLIB=OFF, and
the sdk being built is not a static-only (e.g. WASI), the build fails
due to duplicate custom command rules against the same output path.
In the case of WASI, the static archive should be copied into lib/swift
by the first lipo target, and then the second lipo target should copy it
into lib/swift_static.
```
CMake Error at cmake/modules/SwiftAddCustomCommandTarget.cmake:144 (add_custom_command):
Attempt to add a custom rule to output
/home/build-user/build/buildbot_linux/wasmstdlib-linux-x86_64/lib/swift_static/wasi/libswiftCore.a.rule
which already has a custom rule.
Call Stack (most recent call first):
stdlib/cmake/modules/AddSwiftStdlib.cmake:673 (add_custom_command_target)
stdlib/cmake/modules/AddSwiftStdlib.cmake:2657 (_add_swift_lipo_target)
stdlib/public/core/CMakeLists.txt:401 (add_swift_target_library)
```
Fix some indentation issues.
Change `build-script-impl` to make `build-linux-static` a positive argument.
Fix documentation for `--linux-archs` and `--linux-static-archs` (the options
are comma separated for `build-script`, but semicolon separated for
`build-script-impl`).
Set the default for `linux-static-archs` to `x86_64, aarch64` so that we
install the expected content in the toolchain.
Add missing default for `test_linux_static`.
Make sure to pass down `--skip-build-linux` and `--build-linux-static`.
Factor out config file generation and call it from the install step in `llvm.py`
as well as from the build step.
rdar://123503470
Declare a new `LINUX_STATIC` SDK and configure it.
Add options to set the build architectures for the `LINUX` and
`LINUX_STATIC` SDKs, similar to what we have for Darwin, because
we'll be cross-compiling.
Also add an option to point the build system at the sources for
the musl C library, which we're using for `LINUX_STATIC`.
rdar://123503470
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
This didn't expose any missing imports in the sources of any of the standard
library modules, but that's not entirely surprising. Still, we should have the
feature enabled to test it and prevent regressions from creeping in before the
behavior becomes the default.
Exclude `ExtensionImportVisibility` from module interfaces.
The model for associated types hasn't been fully worked-out for
noncopyable generics, but there is some support already that is being
used by the stdlib for an internal-only (and rather cursed) protocol
`_Pointer` to support `UnsafePointer`, etc.
This patch gates the existing experimental support for associated types
behind a feature flag. This flag doesn't emit feature-guards in
interfaces, since support for it is tied closely to NoncopyableGenerics
and has been there from its early days.
The `.swiftinterface` of the standard library must remain compatible with some
older compilers. Unfortunately, some of those older compilers do not allow the
experimental feature `NoncopyableGenerics` to be enabled in production. To
allow the stdlib to build with non-copyable generics enabled and still have the
older compilers consume its interface, we have to use a new experimental
feature identifier that they do not know about.
Partially resolves rdar://125138945
This is needed to support Apple internal configurations that would fail
consuming such binary swiftmodule (but work as expected when rebuilding
from the swiftinterface).
Addresses rdar://124390643
