An `@_unsafeInheritExecutor` function is unsafe because it doesn't
really "inherit" the executor, it just avoids immediately hopping off
the executor. That means that using `#isolation` within such a
function is fundamentally broken. Ban the use of `#isolation` within
such a function, providing a Fix-It that removes the
`@_unsafeInheritExecutor` attribute and adds a defaulted parameter
isolation: (any Actor)? = #isolation
instead. That's the real, safe pattern that want going forward.
We did say it was unsafe, after all. Part of rdar://131151376.
Not all runtimes can correctly operate with types that use noncopyable
generics. When the generic argument of a type is noncopyable, old
runtimes can't recognize that to correctly check conformances that may
be conditional on those arguments being Copyable, etc.
resolves rdar://126239335
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
Fix the problem that when the only module can be found is an
invalid/out-of-date swift binary module, canImport and import statement
can have different view for if the module can be imported or not.
Now canImport will evaluate to false if the only module can be found for
name is an invalid swiftmodule, with a warning with the path to the
module so users will not be surprised by such behavior.
rdar://128876895
This will ensure that we do not break anyone who has adopted APIs like
CheckedContinuation.resume that now have sending parameters.
An example of where this can come up is shown by the ProcessType in SwiftToolsCore:
```swift
@available(macOS 10.15, iOS 13.0, tvOS 13.0, watchOS 6.0, *)
@discardableResult
public func waitUntilExit() async throws -> ProcessResult {
try await withCheckedThrowingContinuation { continuation in
DispatchQueue.processConcurrent.async {
self.waitUntilExit(continuation.resume(with:))
}
}
}
```
This fails to compile since self.waitUntilExit doesn't expect a function that
takes a sending parameter. We want to give people time to fix such issues.
Exportability checking for non-public imports relies on classic
access-level checks for some of the work. However while conforming
to a local internal protocol from a public type is allow we should
disallow it for imported types, even when imported as internal.
Track exportability issues on conformances to protocols separately
from the general category. Use that information to improve the
diagnostics and report these issues for access-level on imports.
rdar://128420980
If a protocol provides a deprecated default implementation for a requirement
that is not deprecated, the compiler should emit a warning so the programmer
can provide an explicit implementation of the requirement. This is helpful
for staging in new protocol requirements that should be implemented in
conforming types.
Removing the old, ad-hoc diagnostics code improves the diagnostics we
emit, since the existing diagnostics for missing conformances is already
pretty good.
rdar://127369509
There are a number of implicit conversions in Swift, such as to Optional
and to an existential, which are now possible for noncopyable types.
But all type casts are consuming operations for noncopyable types. So
it's confusing when a function that takes a borrowed argument of
optional type appears to be consuming:
```
func f(_ x: borrowing NC?) { ... }
let x = NC()
f(x)
f(x) // error!
```
So, rather than for people to write `x as T?` around all implicit
conversions, require them to write `consume x` around expressions
that will consume some lvalue. Since that makes it much more clear what
the consequences will be.
Expressions like `f(g())`, where you're passing an rvalue to the callee,
are not confusing. And those are exactly the expressions you're not
allowed to write `consume` for, anyway.
fixes rdar://127450418
Allow lifetime depenendence on types that are BitwiseCopyable & Escapable.
This is unsafe in the sense that the compiler will not diagnose any use of the
dependent value outside of the lexcial scope of the source value. But, in
practice, dependence on an UnsafePointer is often needed. In that case, the
programmer should have already taken responsibility for ensuring the lifetime of the
pointer over all dependent uses. Typically, an unsafe pointer is valid for the
duration of a closure. Lifetime dependence prevents the dependent value from
being returned by the closure, so common usage is safe by default.
Typical example:
func decode(_ bufferRef: Span<Int>) { /*...*/ }
extension UnsafeBufferPointer {
// The client must ensure the lifetime of the buffer across the invocation of `body`.
// The client must ensure that no code modifies the buffer during the invocation of `body`.
func withUnsafeSpan<Result>(_ body: (Span<Element>) throws -> Result) rethrows -> Result {
// Construct Span using its internal, unsafe API.
try body(Span(unsafePointer: baseAddress!, count: count))
}
}
func decodeArrayAsUBP(array: [Int]) {
array.withUnsafeBufferPointer { buffer in
buffer.withUnsafeSpan {
decode($0)
}
}
}
In the future, we may add SILGen support for tracking the lexical scope of
BitwiseCopyable values. That would allow them to have the same dependence
behavior as other source values.
