We have a few constructor functions that aren't wrapped in SWIFT_ALLOWED_RUNTIME_GLOBAL_CTOR_BEGIN/SWIFT_ALLOWED_RUNTIME_GLOBAL_CTOR_END and which have started to produce warnings in a new clang version. Explicitly allow these constructors by adding those.
rdar://147703947
This fixes a `copy constructor must pass its first argument by reference` compilation error when compiled with a recent enough Clang (after fe0d3e3764)
* [CS] Decline to handle InlineArray in shrink
Previously we would try the contextual type `(<int>, <element>)`,
which is wrong. Given we want to eliminate shrink, let's just bail.
* [Sema] Sink `ValueMatchVisitor` into `applyUnboundGenericArguments`
Make sure it's called for sugar code paths too. Also let's just always
run it since it should be a pretty cheap check.
* [Sema] Diagnose passing integer to non-integer type parameter
This was previously missed, though would have been diagnosed later
as a requirement failure.
* [Parse] Split up `canParseType`
While here, address the FIXME in `canParseTypeSimpleOrComposition`
and only check to see if we can parse a type-simple, including
`each`, `some`, and `any` for better recovery.
* Introduce type sugar for InlineArray
Parse e.g `[3 x Int]` as type sugar for InlineArray. Gated behind
an experimental feature flag for now.
Android should use the dispatch based, Linux platform executor. However,
Android reports as `os(Android)` rather than `os(Linux)`. This adjusts
the condition to ensure that we have a platform executor factory for
Android.
These were split out in #79751. However, this split is not needed for
these. Furthermore, modulemaps have bugs when it comes to re-exporting
some modules, resulting in missing exports.
* [Concurrency] Fix templated code in Task+startSynchronously.swift
rdar://147348183
The gyb code always dropped the `throws` modifier, no matter which case was being processed.
* Update Task+startSynchronously.swift.gyb
* Fix abi tests
Change task ids to be formatted using decimal instead of hex.
An example of previous signposts:
```
task=e resumefn=0x2807722bc jobPriority=0 isChildTask=0, isFuture=1 isGroupChildTask=0 isAsyncLetTask=0 parent=0 group=0x0 asyncLet=0x0
```
this will now show `task=14` instead of `task=e`
Do not rely on the @_unsafeNonescapableResult attribute. That attribute is only
for temporarily working around bugs! And it only affects lifetime diagnostics within
the function. It has no affect on the caller's diagnostics, so it won't solve
this problem:
func macroGeneratedThunk() -> CxxSpan<Int> {
return _unsafeRemoveLifetime(Span...)
}
We cannot simply add @_unsafeRemoveLifetime to the thunk, because SwiftSyntax
does not natively support the attribute. We don't want to add SwiftSyntax
support because this attribute will never be supported syntax!
Instead, use `_overrideLifetime` copying the `Void` type to remove a dependency:
func macroGeneratedThunk() -> CxxSpan<Int> {
return _cxxOverrideLifetime(Span..., copying: ())
}
It's hard to tell why a crash occurred with just "Could not allocate memory." Modify the message to include the size/alignment, which will help distinguish between an actual lack of memory and a request for an excessively large allocation.
While we're in there, add \n to a bunch of other fatal error helper functions that didn't have it.
_swift_taskGroup_cancelAllChildren relies on there being no concurrent modification when called from the owning task, but this is not guaranteed.
Rearrange things to always take the owning task's status record lock when walking the group's children. Split _swift_taskGroup_cancelAllChildren into two functions, one which assumes/requires the lock is already held, and one which acquires the lock. We don't have the owning task in this case, but we can either get it from the current task, or by looking at the parent of the child task we're working on.
rdar://147172991
`CooperativeExecutor` should fall back to heap allocations if the task
allocator isn't available when it's enqueuing delayed jobs.
Also, remove the reference to `DispatchGlobalExecutor` from the
custom executor test.
rdar://141348916
