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
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.
_Concurrency is not used in the module, and having it as a dependency causes a ninja error when trying to build stdlib without `-D SWIFT_ENABLE_EXPERIMENTAL_CONCURRENCY=YES`:
```
ninja: error: 'stdlib/private/OSLog/swift_Concurrency-swiftmodule-macosx-arm64', needed by 'stdlib/private/OSLog/OSX/arm64/OSLogTestHelper.o', missing and no known rule to make it
```
The compiler stubs for testing the OSLog implementation are in need of an update. This change updates the stubs to be consistent with the current OSLog implementation, updates the existing tests, and adds new tests for String and metatype interpolations.
rdar://69719729
module to contain only code necessary for testing the compiler
optimizations and diagnostics. This commit comprises the following changes:
1. Rename the OSLogPrototype module to OSLogTestHelper and rename the files.
2. Make the private module: OSLogTestHelper independent of os overlay.
3. Simplify the os log test suites and make them not perform logging.
4. Enable the os log test suites on all platforms.
<rdar://problem/60542172>
The format specifier constructed by the os log implementation uses '*' for
width and precision, and passes those values to the os_log ABIs as additional
arguments of the message. (The precision/alignment arguments have the
type: count).
Update tests to handle this change.
os log overlay @_transparent so that they will be inlined in their
callers even annotated as @_optimize(none).
Make the OSLogPrototypeCompileTest.swift test suite check only the
output of the OSLogOptimization pass instead of the output of the
Onone pipeline. This will make the tes more resilient to adding
mandatory optimizations later in the pass pipeline. Also, remove
a duplicate test from the OSLogPrototypeExecTest suite.
Also, add aliases for the logging levels for source compatibility with swift-server
side logging. Create a new initializer of Logger that can directly accept an
existing os log object of type `OSLog`. This aids in porting uses of existing
os_log API to the new API.
The extensions for supporting NSObjects are in the file:
OSLogNSObjectType.swift. This creates a new dependency for the
OSLogPrototype overlay on the module: ObjectiveC. However,
ObjectiveC is already a dependency for the os module.
This patch includes tests for the NSObject extensions.
In addition, this patch contains a few other minor changes.
1. It makes the `osLog` function public (so that it can be
used by clients directly). 2. It fixes a lifetime-related
bug in the osLog function implementation. 3. It improves
the OSLogPrototypeExecTest suite by refactoring a few
helper functions.
and instead directly access the array stored in OSLogArguments.
This will make constant folding of the array possible when its
contents are inferred at compile time by the OSLogOptimization pass.
of OSLogMessage constant evaluable and remove @_transparent annotation
from the methods. Also, improve diagnostics in the OSLogOptimization
pass as now it rely on seeing the appendInterpolation/Literal calls.
library so that the type: OSLogByteBufferBuilder is no longer needed.
This would make backward deployment of code using the new log APIs
easier, besides other minor benefits.
@_semantics("constant_evaluable") annotation to denote constant
evaluable functions.
Add a test suite that uses the sil-opt pass ConstantEvaluableSubsetChecker.cpp
to check the constant evaluability of function in the OSLog
overlay.
interpolation of Int types in the new os_log APIs so that it is
easier to extend to other integer types. Based on this, add support
for interpolating Int32 types.
the builtin.globalStringTablePointer to the new OSLog overlay.
Modify the new OSLog implementation to use this SPI instead of
`withCString` to pass the (compiler-generated) format string to
the C os_log_impl ABI.
Move the OSLogOptimization pass before constant propagation in
the pass pipeline so that the SPI and the builtin it uses can be
folded to a string_literal instruction.
Update OSLogTests to work with the changes in the implementation.
There are situations where you want to build against a libc that is out
of tree or that is not the system libc (Or for cross build scenarios).
This is a change for passing the -sdk and include paths for things like
this.
