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
Custom main and global executors work hasn't passed Swift Evolution yet,
so we need to avoid leaking it as API until it does.
To that end, underscore all the things.
rdar://151147606
If you use SwiftStdlibCurrentOS availability, you will be able to
use new types and functions from within the implementation. This
works by, when appropriate, building with the CurrentOS availability
set to the current deployment target.
rdar://150944675
Previously there was still a sneaky hop which caused ordering issues.
This introduced a specific test startSynchronously_order which checks
that the task enqueues indeed are "immediate" and cleans up how we
handle this.
This also prepares for the being discussed in SE review direction of
this API that it SHOULD be ALLOWED to actually hop and NOT be
synchronous at all IF the isolation is specified on the closure and is
DIFFERENT than the callers dynamic isolation.
This effectively implements "synchronously run right now if dynamically
on the exact isolation as requested by the closure; otherwise enqueue
the task as usual".
resolves rdar://149284186
cc @drexin
As of the custom main/global executor changes, there is a race in
`_runAsyncMain()` to construct the main executor; if this goes the wrong way,
the IRGen async tests, which use this function, can fail.
Fix by explicitly constructing a task and enqueing it on the main executor,
instead of detaching a task and trying to hop to it.
rdar://148506256
* [Concurrency] Adjust task escalation APIs to SE accepted shapes
* adjust test a little bit
* Fix closure lifetime in withTaskPriorityEscalationHandler
* avoid bringing workaround func into abi by marking AEIC
Otherwise in certain cases, we will run into:
1588 | extension GlobalActor {
| | `- error: 'GlobalActor' is only available in macOS 10.15 or newer
| `- note: add @available attribute to enclosing extension
1589 | @available(SwiftStdlib 6.2, *)
1590 | @_silgen_name("_swift_task_isCurrentGlobalActor")
rdar://146848568
Remove `supportsScheduling` in favour of a type-based approach.
Update the storage for `ClockTraits` to `UInt32`.
Adjust ordering of executors for `currentExecutor`.
rdar://141348916
Reorganise the Concurrency code so that it's possible to completely
implement executors (both main and global) in Swift.
Provide API to choose the desired executors for your application.
Also make `Task.Sleep` wait using the current executor, not the global
executor, and expose APIs on `Clock` to allow for conversion between
time bases.
rdar://141348916
Following the approach taken with the concurrency-specific type
descriptors, register a hook function for the "is current global actor"
check used for isolated conformances.
Extend the metadata representation of protocol conformance descriptors
to include information about the global actor to which the conformance is
isolated (when there is one), as well as the conformance of that type to
the GlobalActor protocol. Emit this metadata whenever a conformance is
isolated.
When performing a conforms-to-protocol check at runtime, check whether
the conformance that was found is isolated. If so, extract the serial
executor for the global actor and check whether we are running on that
executor. If not, the conformance fails.
The `swift_task_escalate` is defined to return the new priority of the
task after the escalation but the silgen_name'd function did not have
the return type specified.
Follow up to 18c25845d6
* [Concurrency] Initial steps for startSynchronously for Task
* [Concurrency] Rename to _startSynchronously while in development
* [Concurrency] StartSynchronously special executor to avoid switching
* startSynchronously bring back more info output
* [Concurrency] startSynchronously with more custom executor tests
* add missing ABI additions to test for x86
* [Concurrency] gyb generate _startSynchronously
* [Concurrency] %import dispatch for Linux startSynchronously test
* [Concurrency] Add TaskGroup.startTaskSynchronously funcs
* [Concurrency] DispatchSerialQueue does not exist on linux still
Previously these records were not used at all, so changing this has no
impact on existing runtimes. Note that we changedd the FunctionType
because the previous one was slightly incorrect -- the context comes
LAST in the type, not first.
This routine takes a synchronous non-throwing main actor isolated closure
without a result. If we are dynamically on the main actor, we just run the
closure synchronously. Otherwise, we run a new task on the main actor and call
the closure on that.
This builds on top of the previous commit by using
swift_task_isCurrentExecutorWithFlags in the implementation of this function.
To backwards deploy this function on Darwin, I used some tricks from libdispatch
to validate that we are on the main queue.
- Use the spelling "canceled" per Apple Style Guide
- Use code voice for symbol name
- Use contractions
- Avoid parenthesis for asides
- Change "it" to "that function" to reduce ambiguity
