Introduce a constructor that takes an `llvm::VersionTuple` directly, instead of
needing to spell out `VersionRange::allGTE(<tuple>)` which is unnecessarily
verbose.
The generality of the `AvailabilityContext` name made it seem like it
encapsulates more than it does. Really it just augments `VersionRange` with
additional set algebra operations that are useful for availability
computations. The `AvailabilityContext` name should be reserved for something
pulls together more than just a single version.
Upstreams the necessary changes to compile references to `@backDeployed`
declarations correctly when a `macabi` target triple or a `-target-variant` is
specified.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
* Allow normal function results of @yield_once coroutines
* Address review comments
* Workaround LLVM coroutine codegen problem: it assumes that unwind path never returns.
This is not true to Swift coroutines as unwind path should end with error result.
This adds SIL-level support and LLVM codegen for normal results of a coroutine.
The main user of this will be autodiff as VJP of a coroutine must be a coroutine itself (in order to produce the yielded result) and return a pullback closure as a normal result.
For now only direct results are supported, but this seems to be enough for autodiff purposes.
When comparing a requirement that uses typed throws and uses an
associated type for the thrown error type against a potential witness,
infer the associated type from the thrown error of the
witness---whether explicitly specified, untyped throws (`any Error`),
or non-throwing (`Never`).
Lower the thrown error type into the SIL function type. This requires
very little code because the thrown error type was already modeled as
a SILResultInfo, which carries type information. Note that this
lowering does not yet account for error types that need to passed
indirectly, but we will need to do so for (e.g.) using resilient error
types.
Teach a few places in SIL generation not to assume that thrown types
are always the existential error type, which primarily comes down to
ensuring that rethrow epilogues have the thrown type of the
corresponding function or closure.
Teach throw emission to implicitly box concrete thrown errors in the
error existential when needed to satisfy the throw destination. This
is a temporary solution that helps translate typed throws into untyped
throws, but it should be replaced by a better modeling within the AST
of the points at which thrown errors are converted.
The property descriptors of `@backDeployed` properties aren't available on OSes
prior to the "back deployed before" OS version, so the descriptors cannot be
referenced by clients that may run against older versions of the library
that defines the property.
See https://github.com/apple/swift/pull/59214 for prior art.
Resolves rdar://106517386
The following program crashed when compiled with the Swift 5.7 and 5.8 compilers:
```
@available(macOS 12, *)
@_backDeploy(before: macOS 99)
public func foo<T>(_ t: __owned T) {
print("foo")
}
class C {
deinit {
print("deinit")
}
}
foo(C())
print("done")
```
```
> ./test
foo
deinit
[1] 49162 segmentation fault ./test
```
The root cause is that generated SIL for the back deployment thunk for `foo(_:)` included its own `destroy_addr` instruction for the value of `t`, but didn't copy the parameter before passing it to the real function implementation which also destroys the value. The fix is to forward ownership of the parameter values to the called function, which causes cleanup generation to be skipped.
Resolves rdar://104436515
When a throwing function which returns a generic (this is the simplest
example) is back deployed, it gets a back deploy thunk. This back
deploy thunk calls one of two variations of the function, depending on
availability, both which have the same signature and in particular both
return a generic. The result type of that function signature is an
unbound generic.
Previously, that result type was used as is. Consequently the success
blocks for the try_apply instructions in these thunks had arguments of
unbound generic type.
Here, that type is mapped into the context of the function being
emitted. The thunks now have the appropriate bound generic type.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
When computing the availability of a `SILFunction` for linkage the OS version specified in the `@_backDeploy` attribute should be preferred over the version in the `@available` attribute. This ensures that the corresponding symbol is weakly linked when deploying to older OSes than the back deploy "before" version.
Resolves rdar://99962885
The SIL verifier has identified an issue with the SIL generated for property accessors structured like this:
```
public struct S {
@available(macOS, introduced: 12.0)
@_backDeploy(before: macOS 13.0)
public var x: String {
_read {
yield "x"
}
}
}
```
The emitted SIL is invalid because the value `%9` is used after `end_apply` may have ended the lifetime of the value:
```
bb1:
%8 = function_ref @$s4test1SV1xSSvrTwB : $@yield_once @convention(method) (S) -> @yields @guaranteed String9
(%9, %10) = begin_apply %8(%0) : $@yield_once @convention(method) (S) -> @yields @guaranteed String
end_apply %10
yield %9 : $String, resume bb3, unwind bb2
```
The fix is to move the `end_apply` to the resume and unwind blocks, after the value has been yielded to the caller.
Resolves rdar://96879247
