WIP to add more overloads to optimize SIMD codegen on concrete types.
Here we do:
- init(repeating:)
- init(lowHalf:highHalf:)
These are always inlined, even in debug, since LLVM knows how to lower
them to one or two instructions on the targets that we care about.
Optimize (the very inefficient) RawRepresentable comparison function call to a simple compare of enum tags.
For example,
```
enum E: String {
case a, b, c
}
```
is compared by getting the raw values of both operands and doing a string compare.
This peephole optimizations replaces the call to such a comparison function with a direct compare of the enum tags, which boils down to a single integer comparison instruction.
rdar://151788987
Consider an `@_alwaysEmitIntoClient` function and a custom derivative
defined
for it. Previously, such a combination resulted different errors under
different
circumstances.
Sometimes, there were linker errors due to missing derivative function
symbol -
these occurred when we tried to find the derivative in a module, while
it
should have been emitted into client's code (and it did not happen).
Sometimes, there were SIL verification failures like this:
```
SIL verification failed: internal/private function cannot be serialized or serializable: !F->isAnySerialized() || embedded
```
Linkage and serialization options for the derivative were not handled
properly,
and, instead of PublicNonABI linkage, we had Private one which is
unsupported
for serialization - but we need to serialize `@_alwaysEmitIntoClient`
functions
so the client's code is able to see them.
This patch resolves the issue and adds proper handling of custom
derivatives
of `@_alwaysEmitIntoClient` functions. Note that either both the
function and
its custom derivative or none of them should have
`@_alwaysEmitIntoClient`
attribute, mismatch in this attribute is not supported.
The following cases are handled (assume that in each case client's code
uses
the derivative).
1. Both the function and its derivative are defined in a single file in
one module.
2. Both the function and its derivative are defined in different files
which
are compiled to a single module.
3. The function is defined in one module, its derivative is defined in
another
module.
4. The function and the derivative are defined as members of a protocol
extension in two separate modules - one for the function and one for the
derivative. A struct conforming the protocol is defined in the third
module.
5. The function and the derivative are defined as members of a struct
extension in two separate modules - one for the function and one for the
derivative.
The changes allow to define derivatives for methods of `SIMD`.
Fixes#54445
<!--
If this pull request is targeting a release branch, please fill out the
following form:
https://github.com/swiftlang/.github/blob/main/PULL_REQUEST_TEMPLATE/release.md?plain=1
Otherwise, replace this comment with a description of your changes and
rationale. Provide links to external references/discussions if
appropriate.
If this pull request resolves any GitHub issues, link them like so:
Resolves <link to issue>, resolves <link to another issue>.
For more information about linking a pull request to an issue, see:
https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
-->
<!--
Before merging this pull request, you must run the Swift continuous
integration tests.
For information about triggering CI builds via @swift-ci, see:
https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci
Thank you for your contribution to Swift!
-->
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
Update availability for CxxSpan<->Span, fix lifetimebound on parameters
with reference type
Because swift-ide-test doesn't care about typechecking,
std-span-interface.swift passed despite containing 2 separate errors.
This updates the test file to properly exercise the entire compilation
pipeline for the macro expansions, by running swift-frontend
-emit-module and calling each macro expansion.
The first issue was that CxxSpan initializers taking [Mutable]Span still
had their availability set to Swift 6.2+, even after back-deploying
caused [Mutable]Span to have availability back to Swift 5.0. Since
_SwiftifyImport expansions copy the availbility of Span, this resulted
in the macro expansions calling unavailable initializers. Interestingly
enough, this manifested itself in the form of a tripped assert in SIL
verification, because although we do now typecheck the expansions from
_SwiftifyImport, the compilation can still keep going after
`shouldEmitFunctionBody` returns false: the macro expansion declaration
is still there, but is now missing its definition, despite not being
external.
The second issue was when parameters with C++ reference types were
annotated with `[[clang::lifetimebound]]`. For parameters with a type
that is `Escapable`, this is normally done using `@lifetime(borrow
foo)`. However C++ reference parameters are imported as `inout`, which
requires the `@lifetime(&foo)` syntax.
rdar://151493400
rdar://151678415
The results of `swift_retain(object:)` and `swift_bridgeObjectRetain(object:)`
should be discardable since it's typcial to not need the pointer returned from
these calls. Suppresses unused result warnings that were generated previously.
We use functions from Shell32.Lib. Ensure that we indicate the
autolinking to the linker. This aides when building with a static
runtime to avoid having to specify the additional library dependency for
clients that are attempting to link against the runtime. This is
particularly important for the CMake compiler check where we would need
to list Shell32 as a required link library.
When ObjC interop is not available, Error values are represented in ErrorObject boxes. These are full HeapObjects, but unowned refcounting ops asserted that the metadata was class metadata. This assert would be hit when destroying an ErrorObject that was weakly referenced. Expand the asserts to accept ErrorObject metadata as well.
rdar://150214921
We need the C++ interop support library to make the build work, as
the Runtime module uses C++ interop.
(Also, we should build it, because some user programs might want to
use C++ interop.)
rdar://147201087
Custom main and global executors work hasn't passed Swift Evolution yet,
so we need to avoid leaking it as API until it does.
To that end, underscore all the things.
rdar://151147606
Prefer `strncpy_s` over `strncpy` which triggers a warning. This
function ensures that the copied string is null-terminated if the string
fits or simply returns an empty string (`\0`) if the string does not
fit. Prefer to use `_TRUNCATE` to copy as much of the name as fits and
ensure that it is null-terminated.
Don't unsafe-cast from the InlineArray struct itself, but from `_storage` which is the actual array buffer.
This also requires making `_storage` a var.
This fixes a deserialization failure in the compiler that occurred while loading the CxxStdlib overlay module:
```
Cross-reference to module 'Swift'
... Optional
... some
... with type <τ_0_0 where τ_0_0 : ~Copyable, τ_0_0 : ~Escapable> (Optional<τ_0_0>.Type) -> (τ_0_0) -> Optional<τ_0_0>
```
This was happening because the overlays were built against a different version of the Swift stdlib than is being used. The compiler is able to rebuild the Cxx and CxxStdlib modules from their textual interfaces. Let's use that feature unconditionally in production toolchains to avoid this kind of binary incompatibilities.
rdar://150416863
The pthread APIs on FreeBSD do not include nullability APIs so the
pthread mutex APIs are imported as pointers to optional values.
Other platforms include nullability APIs and import the pthread APIs as
pointers to the mutex. Splitting the locking primitive type based on the
OS.
Fixes: rdar://150880976
