Because these support functions used to be implemented in C, they could
be present on macOS x86_64, even though Float16 isn't supported
there otherwise. With the new Swift implementation, we can't define
these functions on x86_64 macOS, so remove them from the expected list.
This reimplements the underlying support for `Float16(_:StringSlice)`,
`Float32(_:StringSlice)`, and `Float64(_:StringSlice)` in pure Swift,
using the same core algorithm currently used by Apple's libc. Those
`StringSlice` initializers are in turn used by `Float16(_:String)`,
`Float32(_:String)`, and `Float64(_:String)`.
**Supports Embedded**: This fully supports Embedded Swift and
insulates us from variations in libc implementations.
**Corrects bugs in Float16 parsing**: The previous version of
`Float16` parsing called libc `strtof()` to parse to a 32-bit float,
then rounded to `Float16`. (This was necessary because float16
parsing functions are not widely supported in C implementations.)
This double-rounding systematically corrupted NaN payloads and
resulted in 1 ULP errors for certain decimal and hexadecimal inputs.
The new version parses `Float16` directly, avoiding these errors.
**Modest perforamnce improvement**: The old version had to copy
the Swift string to construct a C string. For inputs longer than
15 characters, this typically required a heap allocation, which added
up to 20% to the runtime. The new version parses directly from a Swift
string, avoiding this copy and heap allocation.
Add a note to missing explicit `Sendable` conformance warning
(produced by `-Wwarning ExplicitSendable`) and a fix-it with
a suggestion to suppress `Senable` conformance via `~Sendable`.
This is a small incremental patch that is designed to address the issue
discovered by 9aa3c5d17c, which is that we
are importing various Decls multiple times.
rdar://164616956
If the MemoryReader can provide a symbol for the context descriptor, use
that instead of building the mangle tree from metadata. This shouldn't
hurt other clients, and would have a few benefits for LLDB:
- Small but numerous memory reads can be expensive for LLDB, building
the mangle tree from a string should be much faster.
- For types with private discriminators, this allows LLDB to provide the
same private discriminator that's in DWARF and in the swiftmodule (as
opposed to using the memory address where the context descriptor lives
at). This means that these private types would have the same mangled
name in every run. LLDB persistently caches field descriptors by name,
but since private discriminators aren't guaranteed to have the same
mangled name over multiple runs, LLDB would often need to invalidate
its entire cache and rebuild it. Using the stable UUID would solve
that issue.
rdar://165950673
Handle the following situation:
```swift
struct S {
func test() {}
static func test(_: S) {}
}
```
Calling `S.test(s)` where `s` has a type `S` without any other context
should prefer a complete call to a static member over a partial
application of an instance once based on the choice of the base type.
The behavior is consistent for double-applies as well i.e.
`S.test(s)()` if static method produced a function type it would be
preferred.
Resolves: rdar://165862285
We generate public metadata lazily which implies it could be emitted into a
different module. If we emit metadata for a public type into a module
other than its "home module" apply "shared" linkage.
_math would be able to build against either the Swift or the clang
module for _Builtin_float; however the build will fail if the Swift
module is present but does not contain the architectures we need, with errors
like
```
<unknown>:0: error: could not find module
'_Builtin_float' for target 'armv7-unknown-linux-android'; found:
aarch64-unknown-linux-android, x86_64-unknown-linux-android, at:
/home/build-user/build/swift-project/Ninja-Release/swift-linux-x86_64/lib/swift/android/_Builtin_float.swiftmodule/armv7-unknown-linux-android
```
In other words, in this situation we are not falling back to the clang
module.
Addresses rdar://165768601
This attribute introduces some conversions between the annotated smart
pointer type and the native swift reference type. In the future we plan
to introduce bridging so the smart pointer type can be hidden in the
signature and we can automatically convert it to the native Swift
reference type on the ABI boundaries.
This PR is using a new way to use swift_attr attributes. Instead of
doing the parsing in the clang importer it falls back to Swift's
attribute parsing and makes sure that the annotation has valid Swift
attribute syntax.
rdar://156521316
This removes the C++ interop compat version mechanism. It was added in mid-2023 and was never used. It complicates the testing story, and makes it harder to reason about the compiler's behavior. It also isn't compatible with explicit module builds.
The flag `-cxx-interoperability-mode` is preserved, so projects that use the flag will continue to build normally.
rdar://165919353
This fixes an assertion failure in ClangImporter that was blocking bootstrapping of the FreeBSD toolchain.
Iterators pointing into `Impl.GetterSetterMap[result]` were being invalidated inside of the for-each loop.
I was unable to minimize the reproducer, so this doesn't include a test case.
rdar://164518108
When an owned value has no lifetime ending uses it means that it is in a dead-end region.
We must not remove and inserting compensating destroys for it because that would potentially destroy the value too early.
Initialization of an object might be cut off and removed after a dead-end loop or an `unreachable`.
In this case a class destructor would see uninitialized fields.
Fixes a mis-compile
https://github.com/swiftlang/swift/issues/85851
rdar://165876726
If followed by a dead infinite loop, the array initialization might have beed removed.
Therefore when inserting a compensating destroy of the array buffer can lead to a crash.
https://github.com/swiftlang/swift/issues/85851
rdar://165876726
This introduces support for converting a Swift closure that captures variables from its surrounding context into an instance of `std::function`, which is useful for working with C++ APIs that use callbacks.
Each instantiation of `std::function` gets a synthesized Swift constructor that takes a Swift closure. Unlike the previous implementation, the closure is _not_ marked as `@convention(c)`. The body of the constructor is created lazily.
Under the hood, the closure is bitcast to a pair of a function pointer and a context pointer, which are then wrapped in a C++ object, `__SwiftFunctionWrapper`, that manages the lifetime of the context object via calls to `swift_retain`/`swift_release` from the copy constructor and the destructor. The `__SwiftFunctionWrapper` class is templated, and is instantiated by ClangImporter.
rdar://133777029
