This TODO has existed since the introduction of the Windows platform and
has not been addressed. The implementation at this point is well tested
in practice. Clean up the warning message and style and remove the
warning.
A first step towards creating safe overloads for C++ APIs using span
(rdar://139074571).
Note that we need to mark span as owned because it the libc++
implementation was mistakenly recognized as owned and might now rely on
span methods like `data` being renamed as `__dataUnsafe`. We will change
it under a new interop version. But for the time being, we want
consistent behavior across stdlib versions.
The PR https://github.com/swiftlang/swift/pull/77857 added windows-specific workaround for https://github.com/swiftlang/swift/issues/77856, that happened after https://github.com/swiftlang/swift/pull/77843. Unfortunately this caused a new issue on windows - https://github.com/swiftlang/swift/issues/78119. It looks like windows is suffering from a similar serialization issue as libstdc++, although its even more complex as the callAsFunction is not only a derived function from a base class, the base class although has a static call operator. In any case, the libstdc++ callAsFunction deserialization fix should align with the static operator () deserialization too, so for now make windows use the same workaround as other platforms to avoid the deserialization crash (77856).
This change was tested on i686 windows too, ensuring that IR verifier crash no longer happens
Hoist the no environment case over the case with the environment. This
ensures that if no environment configuration is selected, the code still
builds. If no environment configuration is selected, `ENVIRON` may still
be defined and that results in calls to elided functions.
Now that Darwin is provided by the system, we no longer need to disable the
system module maps in favour of our own, which also resolves a few other
problems that doing that was creating.
rdar://137201928
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.
The magic symbols specify a version range where clients should reference a @rpath relative path to libswift_Concurrency.dylib instead of the standard absolute path. This version range started at macOS 10.15 and aligned versions, which is the oldest target supported by Concurrency. However, clients that use Concurrency can target earlier OSes as long as they availability-check their use of Concurrency. When targeting something earlier than 10.15, they'd reference the absolute path, then fail to find the back-deployment Concurrency runtime on OS versions that need it.
Fix this by setting the start of the range to macOS 10.9 and aligned, which is the oldest target supported by Swift.
rdar://140476764
* 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)
Darwin defines memcmp with optional pointers. Update SwiftShims to
define it to the same type to avoid deserialization failures where we
get one over the other and the types don't match anymore.
rdar://140596571
The iOS/watchOS/tvOS deployment targets for Cxx and CxxStdlib binaries got unintentionally bumped in b87b263.
This reverts the deployment targets to the older versions.
rdar://140823785 / resolves https://github.com/swiftlang/swift/issues/77909
If a Swift module built with library evolution enabled is an overlay of a C++ module, allow referring to the non-resilient C++ symbols from the Swift code.
Overlays are usually built and shipped along with the C/C++ modules, so library evolution is less of a concern there. A developer providing a Swift overlay for a C++ library would expect to be able to refer to the symbols from the C++ library within the overlay.
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.
In certain versions of libstdc++, `std::hash<std::string>` defines `operator()` in a base class. It looks like Swift is not correctly deserializing an inherited `operator()` for inlinable functions. This change sidesteps the issue by moving the call to `callAsFunction`/`operator()` to the C++ shim layer.
rdar://140358388
