Without this, supported old compilers which don't recognize LifetimeDependence feature but
recognize the NonEscapableTypes feature will run into lifetime dependence inference errors
on the implicit initializer generated for the stdlib's swiftinterface
Due to the ordering of our build system, we may encounter a race when building standard library variants using tools produced by Swift's 'tools' CMake build.
As a workaround, for now, ensure that the compiler building standard library variants does not rely on libSwiftScan built as part of 'tools'.
The _StringProcessing module provides a generic, collection-based
`contains` method that performs poorly for ranges and closed ranges.
This addresses the primary issue by providing concrete overloads
for Range and ClosedRange which match the expected performance for
these operations.
This change also fixes an issue with the existing range overlap tests.
The generated `(Closed)Range.overlap` tests are ignoring the "other"
range type when generating ranges for testing, so all overlap tests
are only being run against ranges of the same type. This fixes things
so that heterogeneous testing is included.
It appears that 'swiftCore' and following associated 'embedded-stdlib-*' targets may begin building before the libSwiftScan library has completed building, which may cause crashes if the compiler process building 'swiftCore' attempts to load it.
Resolves rdar://137674862
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>
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.
