Add @PointerBounds macro
@PointerBounds is a macro intended to be applied by ClangImporter when
importing functions with pointer parameters from C headers. By
leveraging C attributes we can get insight into bounds, esapability, and
(eventually) lifetimes of pointers, allowing us to map them to safe(r)
and more ergonomic types than UnsafePointer.
This initial macro implementation supports CountedBy and Sizedby, but
not yet EndedBy. It can generate function overloads with and without an
explicit count parameter, as well as with UnsafeBufferPointer or Span
(if marked nonescaping), and any of their combinations. It supports
nullable/optional pointers, and both mutable and immutable pointers.
It supports arbitrary count expressions. These are passed to the macro
as a string literal since any parameters referred to in the count
expression will not have been declared yet when parsing the macro.
It does not support indirect pointers or inout parameters. It supports
functions with return values, but returned pointers can not be bounds
checked yet.
Bounds checked pointers must be of type Unsafe[Mutable]Pointer[?]<T>
or Unsafe[Mutable]RawPointer[?]. Count expressions must conform to
the BinaryInteger protocol, and have an initializer with signature
"init(exactly: Int) -> T?" (or be of type Int).
rdar://137628612
---------
Co-authored-by: Doug Gregor <dgregor@apple.com>
We are seeing strange crashes during embedded stdlib build stage on Ubuntu 24.04. These crashes only seem to occur when we dispatch many stdlib emit-module tasks at the same time. While we root-cause it, this change attempts to slow down the process to only two Embedded StdLib tasks at-a-time.
Workaround for rdar://137674862
A `@convention(block)` closure in Swift is completely compatible with Objective-C
and does not need to be wrapped in a `__SwiftValue` box for use.
Previously, it was bridged verbatim when appearing by itself, but
could end up boxed when it went through array bridging.
The test verifies that:
* Objective-C does not see a `__SwiftValue` box
* Swift `type(of:)` does not see a `__SwiftValue` box
* Objective-C can actually call the closure
Resolves rdar://138132321
rdar://138487964
On platforms that don't have reserved bits in objc (including unknown) pointers, we use the spare bits for Swift enums, so they have to be masked out. Blocks don't have reserved bits on any platform.
This reverts commit dd037f896f.
@_transparent on deinit was diagnosed as an error in older compilers
Making Atomic.deinit @_transparent will break compiling newer sdk with older compilers
Fixes rdar://139194948
rdar://139106139
Regular ObjC references do not have unused bits or extra inhabitants for storing enum tags, because they may be tagged pointers. However, ObjC classes that are implemented in Swift do, so we must differentiate between the two.
Functions like `fatalError()` have overloads for Embedded Swift only that take
StaticString instead of String, since String is unavailable. Unfortunately,
many of these overloads create the opportunity for ambiguity in certain
contexts. The easiest way to avoid the ambiguities is to mark each of the
overloads taking `String` as `@_disfavoredOverload`. Another approach that
could work would be to remove the default arguments from the `String` variants
in Embedded Swift only, but that would create even more duplication of source
code so it doesn't seem worth it.
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.
These modules import Darwin which is not in ossa. -enable-ossa-modules
results in a one-time recompilation of dependencies when they are not in ossa.
This is not compatible with Explicit Build Modules when the original invocation
did not have -enable-ossa-modules.
We should build a 64-bit value from the two 32-bit Id fields, but we were shifting one field by the other. Coincidentally, this managed to produce the correct value until the ID goes beyond 2^32, but after that it's weird and wrong.
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]
```
Replace NextLinkType with Item::Kind with more clear definition.
Use llvm::PointerIntPair<>.
Use hierarchy of classes instead of optional fields inside Item.
Combined Storage::copyToOnlyOnlyFromCurrentGroup() into Storage::initializeLinkParent().
Also create parent task marker when copying items created inside withTaskGroup().
Removed Storage::peekHeadLinkType().
