Introduce the first APINotes injection for the Android platform. This
follows the VCRuntime pattern of permitting the SDK to provide API Notes
that augment the system SDK. This adds a workaround for incorrect
nullability on the `fts_open` function in bionic. The system library
itself is fixed at:
https://android-review.googlesource.com/c/platform/bionic/+/3151616
When using direct-cc1 scanning mode, `-clang-target` is passed to
swift-frontend as `-Xcc` option, thus it causes swift IRGen to use
clang-target, instead of `-target` option of swift invocation. Teach
clang importer to restore target triple from swift for codegen option.
rdar://130547690
The only caller is `loadNamedMembers`, and that
passes in a non-optional EffectiveClangContext,
meaning that we'd miss the case when
`getEffectiveClangContext` returns `nullptr`, crashing
in `translateContext`. No test case unfortunately
as I haven't been able to come up with a reproducer.
rdar://129619711
Out of an abundance of caution, we:
1. Left in parsing support for transferring but internally made it rely on the
internals of sending.
2. Added a warning to tell people that transferring was going to
be removed very soon.
Now that we have given people some time, remove support for parsing
transferring.
rdar://130253724
In C interop mode, the return type of builtin functions like 'memcpy' from headers like 'string.h' drops any nullability
specifiers from their return type, and preserves it on the declared return type. Thus, in C
mode the imported return type of such functions is always optional. However, in C++ interop mode, the
return type of builtin functions can preseve the nullability specifiers on their return type,
and thus the imported return type of such functions can be non-optional, if the type is annotated with
`_Nonnull`. The difference between these two modes can break cross-module Swift serialization, as
Swift will no longer be able to resolve an x-ref such as 'memcpy' from a Swift module that uses
C interop, within a Swift context that uses C++ interop. In order to avoid the x-ref resolution
failure, normalize the return type's nullability for builtin functions in C++ interop mode, to
match the imported type in C interop mode.
This fixed an issue when using 'memcpy' from the Android NDK in a x-module context, like
between Foundation (that inlines it) and another user module.
We were trying to instantiate a constructor for `std::function` from a C function pointer with a non-const function pointer type. That worked well on most platforms, where `std::function` defines a single constructor for const and non-const function pointers, but failed on UBI 9.
This fixes a test (`Interop/Cxx/stdlib/use-std-function.swift`) on UBI Linux.
rdar://118026392
These x-refs might not be resolvable using regular lookup from the 'std' module as they could be instantiated/synthesized
by the clang importer. Augment the lookup logic in that case to try clang importer lookup logic that is used during
the conformance to the C++ iterator protocol.
When we have both const and non-const version of a function, we import
the non-cont version with the "Mutating" suffix. This logic, however, is
redundant for static member functions as those can never be marked as
"const" since they don't have a "self" or "this" to mutate.
rdar://120858502
applying `@Sendable` inference for global-actor-isolated function types.
Otherwise, for libraries that do not enable `GlobalActorIsolatedTypesUsability`,
clients that do will encounter mangling mismatches for any library APIs that
have global-actor-isolated function types that are not explicitly `@Sendable`.
Fix the problem that when the only module can be found is an
invalid/out-of-date swift binary module, canImport and import statement
can have different view for if the module can be imported or not.
Now canImport will evaluate to false if the only module can be found for
name is an invalid swiftmodule, with a warning with the path to the
module so users will not be surprised by such behavior.
rdar://128876895
`: AnyObject` was added only if there were no other constraints because
all of them would imply it before, with introduction of `Sendable` this
is no longer the case. Let's add `AnyObject` constraint unconditionally
and let generic signature builder deal with the redundancy.
Resolves: rdar://127520993
