Two are fixes needed in most of the `RawSpan` and `Span` initializers. For example:
```
let baseAddress = buffer.baseAddress
let span = RawSpan(_unchecked: baseAddress, byteCount: buffer.count)
// As a trivial value, 'baseAddress' does not formally depend on the
// lifetime of 'buffer'. Make the dependence explicit.
self = _overrideLifetime(span, borrowing: buffer)
```
Fix#1. baseAddress needs to be a variable
`span` has a lifetime dependence on `baseAddress` via its
initializer. Therefore, the lifetime of `baseAddress` needs to include the call
to `_overrideLifetime`. The override sets the lifetime dependency of its result,
not its argument. It's argument still needs to be non-escaping when it is passed
in.
Alternatives:
- Make the RawSpan initializer `@_unsafeNonescapableResult`.
Any occurrence of `@_unsafeNonescapableResult` actually signals a bug. We never
want to expose this annotation.
In addition to being gross, it would totally disable enforcement of the
initialized span. But we really don't want to side-step `_overrideLifetime`
where it makes sense. We want the library author to explicitly indicate that
they understand exactly which dependence is unsafe. And we do want to
eventually expose the `_overrideLifetime` API, which needs to be well
understood, supported, and tested.
- Add lifetime annotations to a bunch of `UnsafePointer`-family APIs so the
compiler can see that the resulting pointer is derived from self, where self is
an incoming `Unsafe[Buffer]Pointer`. This would create a massive lifetime
annotation burden on the `UnsafePointer`-family APIs, which don't really have
anything to do with lifetime dependence. It makes more sense for the author of
`Span`-like APIs to reason about pointer lifetimes.
Fix#2. `_overrideLifetime` changes the lifetime dependency of span to be on an
incoming argument rather than a local variable.
This makes it legal to escape the function (by assigning it to self). Remember
that self is implicitly returned, so the `@lifetime(borrow buffer)` tells the
compiler that `self` is valid within `buffer`'s borrow scope.
Unsafely discard any lifetime dependence on the `dependent` argument. Return
a value identical to `dependent` with a new lifetime dependence on the
`borrows` argument.
This is required to enable lifetime enforcement in the standard library
build.
* Fix recoverable [U]Int128 division-by-zero
This patch fixes the division-by-zero case in the following methods:
- `Int128/dividedReportingOverflow(by:)`
- `Int128/remainderReportingOverflow(dividingBy:)`
- `UInt128/dividedReportingOverflow(by:)`
- `UInt128/remainderReportingOverflow(dividingBy:)`
* Add preconditions to trapping [U]Int128 division methods.
* Make consistent use of `_slowPath(_:)`.
Jumping on the `_slowPath(_:)` bandwagon like all other integer types.
* Copy existing UInt128 division comments to division operators.
* Add a comment about signed remainder overflow semantics as requested.
I have paraphrased @stephentyrone's and @xwu's review comments to the best of my ability.
Usually this function is inlined anyway. But if it is not (and that can happen), it has a dramatic performance impact. Also, usually code size regresses if this function is not inlined.
The `DebugDescription` macro has been accepted. Additionally, the `DebugDescriptionMacro` feature was not providing conditional declaration as I originally intended. References to the feature are not needed and can be removed.
(cherry-picked from #77738)
However, to do this, we end up changing how amd64 is supported too.
Previously, I had tried to keep some meaningful separation between
platform spelling and LLVM spelling, but this is becoming more difficult
to meaningfully maintain.
Target specifications are trivially converted LLVM triples, and the
module files are looked up by LLVM triples. We can make sure that the
targets align, but then the Glibc to SwiftGlibc import breaks. That could
also be addressed, but then we get to a point where the targets set up
by build-script and referenced by cmake begin to misalign. There are
references in build-script-impl for a potential renaming site, but it's
not quite enough.
It's far simpler to give up and rename to LLVM spellings right at the
beginning. This does mean that this commit is less constrained to just
adding the necessary parts to enable arm64, but it should mean less
headaches overall from differing architecture spellings.
Prior to throwing, Swift emits a call to `swift_willThrow(Typed)`,
which allows various diagnostic tools (such as debuggers and testing
libraries) to intercept errors at the point where they are initially
thrown.
Since `swift_willThrow(Typed)` can be hooked by arbitrary code at
runtime, there is no way for it to meet performance constraints like
@_noLocks or @_noAllocation. Therefore, in a function that has those
performance constraints specified, disable emission of the call to
`swift_willThrow(Typed)`.
Fixes rdar://140230684.
The Span interface requires this. It needs to be able to create dependencies on
UBP values without creating extra temporary copies.
This is only a temporary workaround for:
rdar://140291657 (ASTPrinter: print synthesized conformances on the type
definition, not as an extension)
Until that ASTPrinter bug is fixed, .swiftinterface files drop BitwiseCopyable
conformance on types that have conditionally ~Copyable generic parameters.
Without this fix, the standard library source will break with shortly upcoming
compiler toolchain.
Never explicitly copy a pointer before passing it to an argument that is the
source of a lifetime dependency on the function's return value. That will always
raise a diagnostic error: depending on a temporary value is not the same as
depending on a variable. A temporary value's scope is only the current expression.
Also avoid using ownership modifiers for UnsafePointer. We don't want to treat
them like noncopyable types. They are simply values. Treating them like
noncopyable types creates a lot of overhead in the representation, which is
likely to interfere with diagnostics and optimization.
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.
