Previously, we skipped checking the return type of a function for safety
as we expected to warn at the use of the returned value:
let x = returnsUnsafe()
usesUnsafe(x) // warn here
Unfortunately, this resulted in missing some unsafe constructs that can
introduce memory safety issues when the use of the return value had a
different shape resulting in false negatives for cases like:
return returnsUnsafe()
or
usesUnsafe(returnsUnsafe())
This PR changes the analysis to always take return types of function
calls into account.
rdar://157237301
In Embedded Swift, the `String` type is unavailable. This means that the
overload of `fatalError()` that takes a `String` is also unavailable. Specify a
`StaticString` in the setter for `TaskLocal.projectedValue` to satisfy this
constraint.
The `_SwiftConcurrencyShims` module was imported `@_implementationOnly` which
was causing warnings to be emitted during the stdlib build. The module
currently serves no purpose; the only declaration it contains is a defunct
`_SwiftContext` struct which is not referenced by anything. The module needs to
continue to exist for source compatibility, though, since it is part of the
toolchain and imported publicly from other modules.
because it discusses an implementation detail of the type the comment is
on. Instead, when developers read comments they think about what they
can store inside a task local -- so the comment about "task local must
be a class" led them to believe THEIR types must be classes, while the
comment was explaining the implementation detail of `class
TaskLocal<T>`.
Resolves rdar://117982608
It is no longer necessary to avoid using the `consume` keyword in inlinable
function bodies in the standard library in order to support older compilers.
Partially reverts https://github.com/apple/swift/pull/65599.
Resolves rdar://109165937.
All compilers that must be able to compile the standard library's textual
interface accept the following:
- back deployed functions declared without `@available`
- `@inlinable` back deployed functions
- `defer` blocks in back deployed functions
We can therefore revert the workarounds added in
https://github.com/apple/swift/pull/62946/ and
https://github.com/apple/swift/pull/62928/.
Resolves rdar://104085810
Revert a few unnecessary changes have been made to the _Concurrency module
recently that make its swiftinterface un-parseable by older compilers that we
need to support.
- The `consume` keyword is not understood by older compilers, so including it
in inlinable code is a problem. It has no actual effect on lifetimes where it
was used, so just omit it.
- Don't build the _Concurrency module with -enable-experimental-feature
MoveOnly. The MoveOnly feature is now enabled by default in recent compilers,
so the flag is superfluous when building the dylib. When emitting the
interface, having the feature enabled explicitly exposes code guarded by
`$MoveOnly` to older compilers that do not accept all of the code.
Resolves rdar://108793606
Because `_taskLocalValuePush` and `_taskLocalValuePop` can result in calls
to `swift_task_alloc` and `swift_task_dealloc` respectively, and because
the compiler hasn't been taught about that (e.g.
`SILInstruction::isAllocatingStack`,
`SILInstruction::isDeallocatingStack`, etc), calling them (push and pop)
from a function which makes use the stack for dynamically sized
allocations can result in violations of stack discipline of the form
```
swift_task_alloc // allocates %ptr_1
copy_value_witness // copies into %ptr_1
swift_task_localValuePush // calls swift_task_alloc and allocates %ptr_2
swift_task_dealloc // deallocates %ptr_1
swift_task_localValuePop // calls swift_task_dealloc and deallocates %ptr_2
```
Avoid the problem by not allocating dynamically sized stack space in the
function which calls `_taskLocalValuePush` and `_taskLocalValuePop`.
Split the calls to those functions into `withValueImpl` function which
takes its argument `__owned`. Call that function from `withValue`,
ensuring that the necessary copy (to account for the fact that withValue
takes its argument `__guaranteed` but `_taskLocalValuePush` takes its
`__owned`) and associated stack traffic occur in `withValue`.
Still, allow `withValueImpl` to be inlined. The stack nesting will be
preserved across it.
rdar://107275872
Older versions of the 5.8 compiler have a bug when generating SIL for functions with `@_backDeploy` containing defer blocks (https://github.com/apple/swift/pull/62444) and for now we need the standard library interface to be compatible with those older compilers.
Resolves rdar://104045168
The concurrency runtime now deploys back to macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, which corresponds to the 5.1 release of the stdlib.
Adjust macro usages accordingly.
