This apinote file needs to be accessible in the locally built Android SDK as it's being built with build.ps1, so that swift-foundation can be built with that file present. This change ensures that the file is copied over into the local build directory for that Android SDK, in addition to being included in the installed component
This change also places the component into lib/swift/apinotes, as that's where the clang importer already looks for API notes
This constructor is unsafe, as it allows creating a `std::span` with a count higher than the size of the sequence of objects it refers to. Therefore, when hardening is enabled, an out-of-bounds access won't trap.
We make it deprecated to discourage its use.
Avoid constructing tasks with `-Xcc` options that references clang
CASOptions. This is going to make the cache hit/miss to be dependent on
CAS location/configuraitons.
Instead, only give swift CASOptions to constructed tasks and propagate
the configurations to underlying clang importer.
rdar://132255889
To better investigate reports of an infinite recursion in `hasPointerInSubobjects`, let's add a pretty stack trace entry to get more readable crash reports.
rdar://131366982
The decision to exclude `-Xcc -D` options from swift module hash
actually doesn't help to solve the problem. It wouldn't reduce the
module variants (or the number of swiftmodule build commands) because
the command-line also encodes all the clang PCM dependencies that do get
affected by `-Xcc` flags.
To avoid the false sharing and the nondeterministic build products,
include most of the `-Xcc` flags, except include search path, into swift
module hash.
rdar://132046247
This change is necessary to differentiate between C++ const and non-const types in Swift.
For instance, `const int` and `int` would both be printed as `CInt` in Swift.
After this change, `const int` is stored as `CInt_const`
- when compiling embedded cross compile target standard libraries, include AVR
- add 16-bit pointer as a conditional compilation condition and get the void pointer size right for gyb sources
- attempt to fix clang importer not importing __swift_intptr_t correctly on 16 bit platforms
- changed the unit test target to avr-none-none-elf to match the cmake build
[AVR] got the standard library compiling in a somewhat restricted form:
General
- updated the Embedded Runtime
- tweaked CTypes.swift to fix clang import on 16 bit platforms
Strings
- as discussed in https://forums.swift.org/t/stringguts-stringobject-internals-how-to-layout-on-16-bit-platforms/73130, I went for just using the same basic layout in 16 bit as 32 bit but with 16 bit pointers/ints... the conversation is ongoing, I think something more efficient is possible but at least this compiles and will probably work (inefficiently)
Unicode
- the huge arrays of unicode stuff in UnicodeStubs would not compile, so I skipped it for AVR for now.
Synchronization
- disabled building the Synchronization library on AVR for now. It's arguable if it adds value on this platform anyway.
Control enforcement of member import visibility requirements via a new option,
instead of piggy-backing on the existing IgnoreAccessControl option. Adopt the
option when doing fallback lookups for unviable members so that the compiler
can diagnose the reason that a member is inaccessible more reliably.
Previously, with MemberImportVisibility enabled decls with the package access
level could be mis-diagnosed as inaccessible due to their access level when
really they were inaccessible due to a missing import.
Resolves rdar://131501862.
When the swiftmodule is built with different clang importer arguments,
they can have the same module hash, causing them to be wrongly re-used even
they contains different interfaces. Add ReducedExtraArgs to the module hash to
disambiguate them.
However, some Xcc arguments, most commonly `-D` options do not affect the
swiftmodule being generated. Do not pass `-Xcc -DARGS` to swift
interface compilation to reduce the amount of module variants in the
build.
rdar://131408266
This introduces a secondary flag `-sysroot` for the non-Darwin targets,
primarily Unicies. The intention here is to support a split `-sdk`,
`-sysroot` model where the `-sdk` parameter provides the Swift "SDK"
which augments the native platform's C sysroot which is indicated as
`-sysroot`. For the case of Android, this would allow us to provide a
path to the NDK sysroot and the Swift SDK allowing us to cross-compile
Android binaries from Windows.
`cast<CustomAttr>` never returns nullptr, it either returns a non-null `CustomAttr*` or traps. This if condition was triggering a clang-tidy warning, since it is redundant.
If a C++ `struct Base` declares a method with a Clang attribute that Swift is able to import, and `struct Derived` inherits from `Base`, the method should get cloned from `Base` to `Derived` with its attributes.
Previously we were only cloning one attribute at most due to a bug in `cloneImportedAttributes`. DeclAttributes is an intrusively linked list, and it was being made invalid while iterating over it: `otherDecl->getAttrs().add(attrs)` iterates over the list and calls `otherDecl->add(eachElement)`, which invalidates the iterator after the first iteration.
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.
