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.
By populating the memory cache before loading the module, we can avoid a cycle
where a module is imported that is an overlay, which then triggers
ClangImporter, which then (redundantly) triggers the import of the overlay
module, which would reimport the module again, since it's import is still
underway and it hasn't been entered into the cache yet.
rdar://118846313
When the Swift module is not available, we'll synthesize the
Copyable/Escapable decls into the Builtin module.
In the future, it might be nice to just do this always, and define
typealiases for those types in the stdlib to refer to the ones in the
builtin module.
Use an optional isolated parameter to this new `next(_:)` overload to
keep it on the same actor as the caller, and pass `#isolation` when
desugaring the async for..in loop. This keeps async iteration loops on
the same actor, allowing non-Sendable values to be used with many
async sequences.
Instead of passing a unique_ptr of an opaque type back and forth,
let's just push elements onto an std::vector. For now this change
is completely NFC, but further simplifications will become
possible shortly.
Previously, canImport lookup is not completely working with explicit
module due to two issues:
* For clang modules, canImport check still do a full modulemap lookup
which is repeated work from scanner. For caching builds, this lookup
cannot be performed because all modulemap and search path are dropped
after scanning.
* For swift module, if the canImport module was never actually imported
later, this canImport check will fail during the actual compilation,
causing different dependencies in the actual compilation.
To fix the problem, first unified the lookup method for clang and swift
module, which will only lookup the module dependencies reported by
scanner to determine if `canImport` succeed or not. Secondly, add all
the successful `canImport` check modules into the dependency of the
current module so this information can be used during actual
compilation.
Note the behavior change here is that if a module is only checked in
`canImport` but never imported still needs to be built. Comparing to
implicit module build, this can bring in additional clang modules if
they are only check inside `canImport` but should not increase work for
swift modules (where binary module needs to be on disk anyway) or the
most common usecase for `canImport` which is to check the same module
before importing.
rdar://121082031
The `_diagnoseUnavailableCodeReached()` function was introduced in the Swift
5.9 standard library and employs `@backDeployed` to support compilation of
binaries that target OS releases aligned with earlier Swift releases.
Unfortunately, though, this backdeployment strategy doesn't work well for some
unusual build environments. Specifically, in some configurations code may be
built with a compiler from a recent Swift toolchain and then linked against the
dylibs in an older toolchain. When linking against the older dylibs, the
`_diagnoseUnavailableCodeReached()` function does not exist but the
`@backDeployed` thunks emitted into the binary reference that function and
therefore linking fails.
The idea of building with one toolchain and then linking to the dylibs in a
different, older toolchain is extremely dubious. However, it exists and for now
we need to support it. This PR introduces an alternative
`_diagnoseUnavailableCodeReached()` function that is annotated with
`@_alwaysEmitIntoClient`. Calls to the AEIC variant are now emitted by the
compiler when the deployment target is before Swift 5.9.
Once these unusual build environments upgrade and start linking against a Swift
5.9 toolchain or later we can revert all of this.
Resolves rdar://119046537
Static read-only arrays didn't work when passed to ObjectiveC as NSArray.
The storage class of static read-only arrays doesn't carry information about the Element type.
The new `__SwiftDeferredStaticNSArray` is generic over the element type and doesn't have to rely on the element type information of the array storage.
rdar://94185998
We know the number of the entries. Allocate the storage in ASTContext
directly, then initialize it transforming the bridged values.
Add ASTContext::AllocateTransform() helper function.
Sets the `PreModuleImportCallback`'s setter return type to void to
account for the lambda functions in LLDB's progress reporting not
actually using its return value. Also adds a Doxygen comment for `SetPreModuleImportCallback`
`PreModuleImportCallback` is a variable for a callback function used
specifically by LLDB to report progress updates on importing Swift
modules in LLDB. This commit adds a setter for `PreModuleImportCallback`
for greater flexibility in LLDB and removes the reference to this
variable in the constructor.
Related to https://github.com/apple/llvm-project/pull/7769
rdar://105286354
Extend function type metadata with an entry for the thrown error type,
so that thrown error types are represented at runtime as well. Note
that this required the introduction of "extended" function type
flags into function type metadata, because we would have used the last
bit. Do so, and define one extended flag bit as representing typed
throws.
Add `swift_getExtendedFunctionTypeMetadata` to the runtime to build
function types that have the extended flags and a thrown error type.
Teach IR generation to call this function to form the metadata, when
appropriate.
Introduce all of the runtime mangling/demangling support needed for
thrown error types.
Using symbolic references instead of a text based mangling avoids the
expensive type descriptor scan when objective c protocols are requested.
rdar://111536582
From being a scattered collection of 'static' methods in ScanDependencies.cpp
and member methods of ASTContext. This makes 'ScanDependencies.cpp' much easier
to read, and abstracts the actual scanning logic away to a place with common
state which will make it easier to reason about in the future.
Plus tweak `DefaultDefinitionTypeRequest` caching to support querying the
cached type when dumping. This fixes a crash where type computation is
triggered in the dumper before import resolution in `-dump-parse` mode.
