when building for Apple platforms.
In this scenario we are not building our own Foundation,
but we are importing the one from the underlying SDK -- this in turns
requires Observation, which is something we typically build.
Addresses rdar://162286123
This reverts commit 4a95275bde.
I remove the dependency looking at the modules that StdlibUnittest
directly imports -- but it turns out we import StringProcessing
indirectly as a result of importing Foundation from e.g. the underlying
Apple SDKs.
Addresses rdar://158797152
Since #64187 we are not importing automatically StringProcessing when
building the stdlib -- this is especially important for StdlibUnittest,
since it needs to run on older OSes.
Addresses rdar://157622116
The SDK overlays have been provided in the Apple SDKs for many years, and the interface and implementation has diverged in more recent years such that trying to build the Swift version no longer works. Remove all of the dead code.
rdar://151889154
... that would import that as a result of importing Darwin from the SDK.
Amend my previous change to Differentiation and Distributed in this
sense.
Addresses rdar://150400049
In Xcode 16 SDKs there seem to be two `errno` visible for some files,
one in the `Darwin` module, and one in the `_errno` module (which seems
new for this Xcode version).
Disambiguate the references by prepending `Darwin`, which should be the
one that was being used before Xcode 16 SDKs.
Everywhere there's a `SWIFT_MODULE_DEPENDS_LINUX Glibc`, there should be
a corresponding `SWIFT_MODULE_DEPENDS_LINUX_STATIC Musl`.
This usually won't bite us, depending on build order and parallelism, but
I hit one of these yesterday so went looking to see if there were any
others.
rdar://136208589
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 patch goes through and adds zippering and the swift module
dependencies to a bunch of pieces of the swift runtimes. Here's to
hoping I hit everything that needed to be hit. :D
With this patch, I'm seeing the appropriate modules under
lib/swift/maccatalyst, so things seem to be working right.
These two modules themselves depend on modules that implicitly import the _StringProcessing library. Take OSLog as an example, which imports ObjectiveC, which implicitly imports _StringProcessing. Thus, we can get into the following bad scenario:
- A compiler at module format X builds _StringProcessing
- A rebase is performed and the compiler is rebuilt at module format Y > X
- OSLog builds before _StringProcessing (since it has no dependency)
- But _StringProcessing is at module format X < Y, so we have to rebuild it
This normally manifests as an error at the desks of compiler engineers about a mismatch in the module format for _StringProcessing. Let's fix that by making CMake schedule _StringProcessing before them.
SWIFT_STDLIB_SINGLE_THREADED_RUNTIME is too much of a blunt instrument here.
It covers both the Concurrency runtime and the rest of the runtime, but we'd
like to be able to have e.g. a single-threaded Concurrency runtime while
the rest of the runtime is still thread safe (for instance).
So: rename it to SWIFT_STDLIB_SINGLE_THREADED_CONCURRENCY and make it just
control the Concurrency runtime, then add a SWIFT_STDLIB_THREADING_PACKAGE
setting at the CMake/build-script level, which defines
SWIFT_STDLIB_THREADING_xxx where xxx depends on the chosen threading package.
This is especially useful on systems where there may be a choice of threading
package that you could use.
rdar://90776105
SWIFT_STDLIB_SINGLE_THREADED_RUNTIME is too much of a blunt instrument here.
It covers both the Concurrency runtime and the rest of the runtime, but we'd
like to be able to have e.g. a single-threaded Concurrency runtime while
the rest of the runtime is still thread safe (for instance).
So: rename it to SWIFT_STDLIB_SINGLE_THREADED_CONCURRENCY and make it just
control the Concurrency runtime, then add a SWIFT_STDLIB_THREADING_PACKAGE
setting at the CMake/build-script level, which defines
SWIFT_STDLIB_THREADING_xxx where xxx depends on the chosen threading package.
This is especially useful on systems where there may be a choice of threading
package that you could use.
rdar://90776105
Based on its argument names and messages, `expectEqual` and friends expects the expected value of the calculation being tested to be provided as its first argument, and the actual value as the second:
```
expectEqual(4, 2 + 2)
```
This does not always match actual use -- folks like myself find the opposite ordering far more natural:
```
expectEqual(2 + 2, 4)
```
`expectEqual` currently uses the `expected`/`actual` terminology in its failure messages, causing confusion and needless suffering.
Change `expectEqual`'s declaration and error messages to use a naming scheme that does not assume specific roles for the two arguments. (Namely, use `first`/`second` instead of `expected`/`actual`.)
An alternative way to solve this would be to use argument labels, as in `expectEqual(expected: 4, actual: 2 + 2)`, or to introduce some sort of expression builder scheme such as `expect(2 + 2).toEqual(2)`. These seem needlessly fussy and overly clever, respectively.
This change adds support for WASI in stdlib tests. Some tests that expect a crash to happen had to be disabled, since there's currently no way to observe such crash from a WASI host.
* Enforce using headers from Swift's LLVMSupport fork and not llvm-project when building stdlib
* [LLVMSupport] Re-import LLVMSupport .cpp and .h files from 9ff3a9759b7c2f146e7f46e4aebc60453c577c5a from apple/llvm-project
Done via the following commands, while having llvm-project checked out at 9ff3a9759b7c2f146e7f46e4aebc60453c577c5a, a
commit on the stable/20210726 branch of apple/llvm-project, <9ff3a9759b>:
for i in swift/stdlib/public/LLVMSupport/*.cpp ; do cp llvm-project/llvm/lib/Support/$(basename $i) $i ; done
for i in swift/stdlib/include/llvm/ADT/*.h; do cp llvm-project/llvm/include/llvm/ADT/$(basename $i) $i ; done
for i in swift/stdlib/include/llvm/Support/*.h; do cp llvm-project/llvm/include/llvm/Support/$(basename $i) $i ; done
cp llvm-project/llvm/include/llvm/ADT/ScopeExit.h swift/stdlib/include/llvm/ADT/ScopeExit.h
cp llvm-project/llvm/include/llvm/ADT/Twine.h swift/stdlib/include/llvm/ADT/Twine.h
cp llvm-project/llvm/include/llvm/Support/raw_ostream.h swift/stdlib/include/llvm/Support/raw_ostream.h
* [LLVMSupport] Re-namespace the LLVMSupport fork after re-forking by re-applying b72788c27a
More precisely:
1) git cherry-pick b72788c27a
2) manually resolve the conflict in AlignOf.h by keeping the HEAD's version of the chunk and discarding the cherry-pick's change
3) git add AlignOf.h
4) git status | grep "deleted by us" | awk '{print($4)}' | xargs git rm
5) git cherry-pick --continue
Original namespacing commit message:
> This adds the `__swift::__runtime` inline namespace to the LLVMSupport
> interfaces. This avoids an ODR violation when LLVM and Swift are in the
> same address space. It also will aid in the process of pruning the
> LLVMSupport library by ensuring that accidental leakage of the llvm
> namespace does not allow us to remove symbols which we rely on.
* [LLVMSupport] Re-apply "pruning" on re-forked LLVMSupport from bb102707ed
This re-applies the "pruning" commit from bb102707ed, which did the following:
- Remove many whole files,
- Remove "epoch tracking" and "reverse iteration" support from ADT containers
- Remove "ABI break checking" support from STLExtras
- Remove float parsing functions from StringExtras.h
- Remove APInt/APSInt dependencies from StringRef.h + StringRef.cpp (edit distance, int parsing)
- Remove some variants of error handling and dependency of dbgs() from ErrorHandling.h and ErrorHandling.cpp
We don't need to do the whole-file-removal step, because that's already done, but the rest is re-applied by doing:
1) git cherry-pick bb102707ed
2) manually resolving conflict in ADT/DenseMap.h by keeping HEAD's version of the chunk and removing epoch tracking from it
3) manually resolving conflict in ADT/STLExtras.h by keeping HEAD's version of the chunk and removing ABI check checking from it
4) manually resolving conflict in ADT/StringExtras.h by deleting the whole chunk (removing APInt/APSInt dependent functions)
5) manually resolving conflict in ErrorHandling.cpp by force-applying the cherry-pick's version (removing write() calls and OOM callback)
6) manually resolving the three conflicts in CMakeLists.txt files by keeping HEAD's version completely
7) git add stdlib/include/llvm/{ADT/StringSwitch.h,ADT/Twine.h,Support/raw_ostream.h}
Original commit description:
> Reduce LLVMSupport to the subset required for the runtime. This reduces
> the TCB and the overheads of the runtime. The inline namespace's
> preservation ensures that ODR violations do not occur.
* [LLVMSupport] Re-apply all post-import modifications on LLVMSupport that the Swift's fork has
Since the previous commits re-imported "vanilla" versions of LLVMSupport, we need to re-apply all modifications that the Swift's fork has made since the last import. More precisely:
1) git diff 7b70120440cd39d67a595a7d0ea4e828ecc6ee44..origin/main -- stdlib/include/llvm stdlib/public/LLVMSupport | git apply -3 --exclude "stdlib/include/llvm/Support/DataTypes.h" --exclude "stdlib/include/llvm/Config/llvm-config.h.cmake"
2) manually resolve conflict in STLExtras.h by applying the "__swift::__runtime" prefix to HEAD's version
3) manually resolve conflicts in StringSwitch.h by keeping HEAD's version (removing the Unicode BOM marker at the beginning of the file, keeping LLVM's version of the string functions)
4) manually resolve conflict in SwapByteOrder.h by adding the `defined(__wasi__)` part into the #if
* [LLVMSupport] Drop remaining dependencies on APSInt.h, Error.h, DataTypes.h and STLForwardCompat.h
Most cases can drop the #includes without any changes, in some cases there are
straighforward replacements (climits, cstdint). For STLForwardCompat.h, we need
to bring in parts of STLForwardCompat.h from llvm-project.
* [LLVMSupport] Remove raw_ostream.h and drop dependencies to it from the runtime
* [LLVMSupport] Simplify error reporting in SmallVector and avoid using std::string when producing fatal errors messages
Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
Introduce "SwiftStdlib x.y"-style availability macros for all known releases of the stdlib, adding them to the swift flags of all Swift libraries and tests.
The concurrency runtime now deploys back to macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, which corresponds to the 5.1 release of the stdlib.
Adjust macro usages accordingly.
The concurrency runtime now deploys back to macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, which corresponds to the 5.1 release of the stdlib.
Adjust the definition of the SwiftStdlib availability macro accordingly.
