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.
There cannot be undefined behavior at compile time, so these warnings can be
ignored when `offsetof` is used in a static assert:
```
warning: offset of on non-standard-layout type 'AsyncTask' [-Winvalid-offsetof]
```
`Builtin.FixedArray<let N: Int, T: ~Copyable & ~Escapable>` has the layout of `N` elements of type `T` laid out
sequentially in memory (with the tail padding of every element occupied by the array). This provides a primitive
on which the standard library `Vector` type can be built.
For types like `Atomic` and `Mutex`, we want to know that even though they are
technically bitwise-takable, they differ from other bitwise-takable types until
this point because they are not also "bitwise-borrowable"; while borrowed,
they are pinned in memory, so they cannot be passed by value as a borrowed
parameter, unlike copyable bitwise-takable types. Add a bit to the value witness
table flags to record this.
Note that this patch does not include any accompanying runtime support for
propagating the flag into runtime-instantiated type metadata. There isn't yet
any runtime functionality that varies based on this flag, so that can
be implemented separately.
rdar://136396806
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
We want to use Runtime::StoredSize so the layout is correct when using an external Runtime template. size_t is correct in-process but may not be correct out of process.
It cannot be used for executing general-purpose work, because such function would need to have a different signature to pass isolated actor instance.
And being explicit about using this method only for deinit allows to use object pointer for comparison with executor identity.
* [Concurrency] Fix task excutor handling of default actor isolation
The task executor API did not properly account for taking the default
actor locking into account when running code on it, we just took the job
and ran it without checking with the serial executor at all, which
resulted in potential concurrent executions inside the actor --
violating actor isolation.
Here we change the TaskExecutor enqueue API to accept the "target"
serial executor, which in practice will be either generic or a specific
default actor, and coordinate with it when we perform a
runSynchronously.
The SE proposal needs to be amended to showcase this new API, however
without this change we are introducing races so we must do this before
the API is stable.
* Remove _swift_task_enqueueOnTaskExecutor as we don't use it anymore
* no need for the new protocol requirement
* remove the enqueue(_ job: UnownedJob, isolatedTo unownedSerialExecutor: UnownedSerialExecutor)
Thankfully we dont need it after all
* Don't add swift_defaultActor_enqueue_withTaskExecutor and centralize the task executor getting to enqueue()
* move around extern definitions
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
When using a future adapter, the resume context may not be valid after the task starts running. Only peer through the adapter when we're starting to run.
rdar://126298035
We still only parse transferring... but this sets us up for adding the new
'sending' syntax by first validating that this internal change does not mess up
the current transferring impl since we want both to keep working for now.
rdar://128216574
This fixes a crash at runtime when destroying a Swift array of values of a C++ foreign reference type.
Swift optimizes the amount of metadata emitted for `_ContiguousArrayStorage<Element>` by reusing `_ContiguousArrayStorage<AnyObject>` whenever possible (see `getContiguousArrayStorageType`). However, C++ foreign reference types are not `AnyObject`s, since they have custom retain/release operations.
This change disables the `_ContiguousArrayStorage` metadata optimization for C++ reference types, which makes sure that `swift_arrayDestroy` will call the correct release operation for elements of `[MyCxxRefType]`.
rdar://127154770
