functions.
These were introduced in an early draft implementation of async let, but
never used by a released compiler. They are not used as symbols by any
app binaries. There's no reason to keep carrying them.
While I'm at it, dramatically improve the documentation of the remaining
async let API functions.
In several places, there was the same or similar code to either do
a symlink or use copy/copy_if_different/copy_directory in Windows
systems. The checks were also slightly different in some cases.
There is a `SWIFT_COPY_OR_SYMLINK` that can be controlled as a CMake
option, and uses `CMAKE_HOST_UNIX` as default. Change all cases that
I can find to use that value. Also create a parallel value
`SWIFT_COPY_OR_SYMLINK_DIR` to apply to directories.
There is still a couple of cases that are specific to macOS SourceKit
framework which I have left as-is, since symlinks is probably the only
right thing to do there.
There's a case for Windows specifically that uses symlinks (in
523f807694/cmake/modules/SwiftConfigureSDK.cmake (L502))
which I have not modified as well.
* Adds RangeSet/DiscontiguousSlice to the stdlib
* Remove redundant DiscontiguousSlice.Index: Comparable conformance
* Attempt to fix embedded build
* Attempt to fix macOS test failures
* Fix Constaints/members.swift failure on linux
* Add exceptions to ABI/source checker to fix macOS tests
* Fix incremental dependency test failure
* Remove inlining/unfreeze implementation for future improvements
* Simplify indices(where:) implementation
* Address review feedback
* Add test for underscored, public slice members
* Address feedback on inlining, hashing, and initializing with unordered arrays
* Fix ABI checker issues
* Remove MutableCollection extension for DiscontiguousSlice
* Make insertion return a discardable Bool
* Fix ABI checker tests
* Fix other ABI checker tests due to dropping MutableCollection subscript
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.
This converts the `utils/api_checker` scripts to support Python 3 only.
It removes all `from __future__` imports, and switches any `python`
shebangs to `python3`.
Clang enforces a minimum 13.1 deployment target. The driver, API
checker, and various tests assume 13.0 is a valid minimum. Update these
to reflect the actual 13.1 minimum.
Resolves rdar://84177900
Add the generated ABI baseline for the _Concurency model on x86_64
macOS, along with a test that checks the built _Concurrency model
against that baseline.
Right now, the test is a mess, because we have some ABI breaks to
unwind. Add it so the test passes, and then we'll audit and address
every change.
Fixes rdar://83673282.
In #36381 the swift-api-digester changed from being a standalone tool to
be a symlink of the frontend. With the symlink, the target
swift-api-checker disappeared. In order to keep depending on
symlink_abi_checker_data for the tests, change the mentions of
swift-api-checker to swift-frontend (which is the actual target that
creates the symlink).
* More Python3 lint fixes
Some of the issues addressed include:
* Don't use `l` as a variable name (confusable with `1` or `I`)
* `print` statement does not exist in Py3, use `print` function instead
* Implicit tuple deconstruction in function args is no longer supported,
use explicit splat `*` at the call site instead
* `xrange` does not exist in Py3, use `range` instead
* Better name per review feedback
Framework authors may be interested in comparing the current framework build
against an empty baseline to find public APIs without @available attributes. This
change makes such exercise easier.
The framework baselines are installed at 'lib/swift/FrameworkABIBaseline' and the
tool is inside 'bin'. This patch teaches the executable to locate baselines
from the relative path.
In addition, this patch moves the stdlib ABI/API baselines to the canonical
location so we don't have to check the stability of the stdlib using a
different mechanism from other Swift frameworks.
When running the ABI checker from the build artifact, the executable
should be able to find baselines in the same relative paths as if
it's running from a toolchain.
