This means that they can't use _Int128 for their implementation, but efficient implementation of these using only 64b arithmetic is pretty straightforward, so that's OK. This allows them to be specialized and mostly optimized away in release builds.
The copy operator has been implemented and doesn't use it. Remove
`Builtin.copy` and `_copy` as much as currently possible.
Source compatibility requires that `_copy` remain in the stdlib. It is
deprecated here and just uses the copy operator.
Handling old swiftinterfaces requires that `Builtin.copy` be defined.
Redefine it here as a passthrough--SILGen machinery will produce the
necessary copy_addr.
rdar://127502242
I accidentally copy and pasted the mangled symbol names in the wrong order, so existing callers got directed to the wrong entry points, and things got terribly, terribly wrong.
(We badly need a sensible replacement for these `@_silgen_name` hacks.)
Huge thanks to @edymtt for spotting this!
rdar://127016847
There were two categories of problem for older compilers that consume the
stdlib `.swiftinterface`:
- The `case .some(borrowing x)` syntax isn't accepted; use `_borrowing`
- Various functions that addopted `~Copyable` generic constraints conflict with
the `@usableFromInline` ABI stubs that were left in to preserve compatibility
when the functions are printed with `~Copyable` constraints stripped. The stubs
need to have different names to get out of the way.
Resolves rdar://127132742
The layout of a computed key path component carries an argument buffer for captures, which has
the following layout:
```
---
captured values (subscript indices)
---
generic arguments
---
```
When we reference an externally-defined public property or subscript from a key path, and the
external declaration has a property descriptor, then the generic arguments for the external
declaration get appended to the end of this buffer, giving:
```
---
captured values (subscript indices)
---
generic arguments
---
external property's generic arguments
---
```
The convention for key path accessors to bind their generic environment is thus to unpack them
from the end of the argument buffer, so that the external keypath's accessors can find the
arguments to bind the external generic environment while still allowing the enclosing key path
to save the original captured generic environment (which may be necessary to capture the
appropriate conditional and/or retroactive `Equatable` and `Hashable` conformances for
subscript indices).
However, our code generation for binding the generic arguments out of the argument buffer
contained a flawed optimization: for a property, we know there are never any captured values,
so I had assumed that the generic parameters could always be bound from the beginning of the
argument buffer, assuming that the generic parameters make up the totality of the buffer. This
falls over for external property descriptor references when the key path itself captures a
generic environment, since the external property's expected generic environment appears after
the key path's original generic environment. We can fix this by removing the conditional
entirely, and always adjusting the offset we load the generic environment from to look at the
end of the buffer. Fixes rdar://125886333.
This protocol appears in the stdlib as scaffolding for the
`NonescapableTypes` feature, which is still experimental and not gone
through evolution as an approved addition to the stdlib.
Rather than delete it from the stdlib, because it needs to still remain
to support that feature work, gate references to it behind a feature
flag.
Additionally, prevent documentation from seeing this declaration.
rdar://126705184
The new ~Copyable generalizations have changed the function signature enough that alternative definitions of `map`/`flatMap` in existing code that used to be considered to shadow the originals no longer do so. This leads to use sites becoming ambiguous — a source break.
While we consider approaches to resolve this on the compiler side, let’s try slapping a `@_disfavoredOverload` on these and see if that helps.
https://github.com/apple/swift/pull/73045 has uncovered a compiler crash with existing code of this form:
try withExtendedLifetime(statement) { // 💥silgen crash
do {
try dbPool.close()
XCTFail("Expected Error")
} catch DatabaseError.SQLITE_BUSY { }
}
This patterns can happen with any of the newly typed throwing entry points, but the source compat suite only seems to have caught this with `withExtendedLifetime`; let’s see if we can get away with only rolling back this one.
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
WebAssembly does not support _Float16 type, so we need to guard the use
of the type. Unfortunately, Clang does not provide a good way to detect
the support of _Float16 type at compile time, so just disable for wasm
targets.
We can easily test all 2**16 values, so let's do it. Also now _Float16 is properly supported in clang, so we can pass arguments to CPP that way, which lets us get snan right on more platforms.
* Break ambiguity for types conforming to both UEC and SVEC
If an encoding container conforms to _both_ UEC and SVEC and does not
itself implement support for [U]Int128, there is an ambiguity between
the two default implementations. Add additional defaults defined on
the intersection of the protocols to resolve this.
* Update abi tests for new ambiguity breakers.
* Revert "Revert count(where:)"
This reverts commit 779ea19a6a.
Now that SE-0220 has been re-accepted, this adds the `count(where:)`
Sequence method to the standard library.
