This attribute allows to define a pre-specialized entry point of a
generic function in a library.
The following definition provides a pre-specialized entry point for
`genericFunc(_:)` for the parameter type `Int` that clients of the
library can call.
```
@_specialize(exported: true, where T == Int)
public func genericFunc<T>(_ t: T) { ... }
```
Pre-specializations of internal `@inlinable` functions are allowed.
```
@usableFromInline
internal struct GenericThing<T> {
@_specialize(exported: true, where T == Int)
@inlinable
internal func genericMethod(_ t: T) {
}
}
```
There is syntax to pre-specialize a method from a different module.
```
import ModuleDefiningGenericFunc
@_specialize(exported: true, target: genericFunc(_:), where T == Double)
func prespecialize_genericFunc(_ t: T) { fatalError("dont call") }
```
Specially marked extensions allow for pre-specialization of internal
methods accross module boundries (respecting `@inlinable` and
`@usableFromInline`).
```
import ModuleDefiningGenericThing
public struct Something {}
@_specializeExtension
extension GenericThing {
@_specialize(exported: true, target: genericMethod(_:), where T == Something)
func prespecialize_genericMethod(_ t: T) { fatalError("dont call") }
}
```
rdar://64993425
Unlike our existing coroutines, async functions run independently within an async coroutine context, and don't
directly yield values back and forth. They therefore mostly behave like normal functions with only an `@async` annotation
to indicate the presence of async suspend points. The `withUnsafeContinuation` primitive requires some instructions
to represent the operation that prepares the continuation to be resumed, which will be represented by
`begin_async_continuation`...`await_async_continuation` regions.
Clarify the function of `__SwiftValue` (used when casting to AnyObject) but remove the actual name.
The name and layout of this type is an internal implementation detail that is not guaranteed and should not be relied on by any code outside of the runtime.
Swift now builds cleanly out of the box as of OpenBSD 6.8-beta.
While there are still more unit test tweaks to be made, document the
preparation and other quirk flags necessary to get a clean build on this
system.
This improves upon the existing documentation to provide a clearer end-to-end
workflow for new contributors and people who wish to build the toolchain
locally but do not intend to submit patches.
We also provide more directions for systematically utilizing our existing
documentation.
