With `NoncopyableGenerics` enabled, we currently lose some ability for
associatedtype inference to find a suitable type witness based on a
value witness. (rdar://118998138)
The stdlib accidentally uses that inference for Sequence.Element,
due to the default witness for `_customContainsEquatableElement`
mentioning `Iterator.Element` whereas the requirement only states
`Element`.
These class methods are internal, but because they are overridden and are
part of a `@usableFromInline`, `@_fixed_layout` class, we they can't be
moved over to typed throws without breaking ABI. However, they are
only ever called from typed-throws functions, which already need a
do...catch dance to downcast the error itself. Make them `throws`
instead, which is ABI-compatible, but eliminates the need for
do...catch hackery in the function itself.
Replace the hackish use of `@_disfavoredOverload` with the more principled
use of `@_silgen_name` for the entrypoint we are maintaining, then rename
these functions in source to `__rethrows_map` to indicate what they're for.
While here, make them `throws` instead of `rethrows`. The ABI is the
same, and `throws` allows us do avoid to do/catch tricks with rethrows
functions.
Adopt typed throws for the `map` operation to propagate thrown error
types through the `map` API. This is done in a manner that is backward
compatible for almost all cases:
* The new typed-throws entrypoint is `@_alwaysEmitIntoClient` so it
can back-deploy all the way back.
* The old `rethrows` entrypoint is left in place, using
`@usableFromInline` with `internal` so it is part of the ABI but not
the public interface, and `@_disfavoredOverload` so the type checker
avoids it while building the standard library itself. The old
entrypoint is implemented in terms of the new one.
Note that the implementation details for the existential collection
"box" classes rely on method overriding of `_map` operations, and the
types are frozen, so we don't get to change their signatures. However,
these are only implementations, not API: the actual API `map`
functions can be upgraded to typed throws.
Note that this code makes use of a known hole in `rethrows` checking
to allow calling between `rethrows` and typed throws. We'll need to do
something about this for source-compatibility reasons, but I'll follow
up with that separately.
This is the 3rd attempt to fix the mismatch, where the actual definition
(e.g. `swift_retainCount`) are defined with C calling-convention and the
callers wrongly expect Swift calling-convention.
The 1st fix broke ABI compatibility by introducing new symbol references
from app-side without any availability checks.
The 2nd fix broke lldb's retain counting feature due to new x-ref to
Clang module in serialized function body by `@_alwaysEmitIntoClient`.
This attemps to avoid introducing serialized x-ref to Clang module by
using new `@_extern(c)` attribute.
Resolves rdar://113910821
Co-authored-by: Karoy Lorentey <klorentey@apple.com>
This precondition checks to make sure that the content-providing
collection isn't larger than the allocated buffer, but was preventing
using a buffer that is the exact same size as the collection.
We don't support generating code for ptrauth builtins with generic
inputs (or non-constant inputs). We rely on specialization/inlining for
such code to work.
After a recent commit (#68843 ) code in IRGen keeps internal unreferenced
functions alive for debugging purposes.
This is a problem for the generic functions in PtrAuth.swift using
ptrauth builtins.
Opt out of this new behavior by sprinkling some pixie dust.
Fixes debug swift standard library builds targeting arm64e.
rdar://117411740
This is an ABI breaking change for Windows. `WCHAR` on Windows is
mapped to `short` (`-fshort-wchar` makes it `unsigned short`). When C++
interop is enabled, `WCHAR` will be mapped to `wchar_t` which is then
mapped to `short` (or `unsigned short` if `-fshort-wchar` is specified).
Correct the mapping type to get the desired behaviour.
