- Fix one placeholder availability I missed in the previous patch
- Add `visionOS 1.0` availability to work around over-pedantic `@_originallyDefinedIn` diagnostic that started appearing in toolchain builds.
Setting this to Self.AsyncIterator.Failure doesn't work because
we replace it with its reduced type Self.Failure, and then if
you run a binary compiled against an older version of the stdlib
that does not declare the Failure associated type, we hit
infinite recursion while instantiating the witness table and
trying to populate the default type witness.
Instead, let's set the default to `any Error`. Associated type
inference is already smart enough to infer the type witness from
the AsyncIterator's Failure type; we don't need to rely on the
default mechanism for that.
Fixes rdar://129605725.
PR #74394 removed a field from `struct MetadataSections` whose layout is ABI.
So restore that field as an unused padding field to preserve the layout of all
the other fields in that struct.
without relying on spare bit information in the reflection metadata
(which was added in #40906). As a result, we can remove the
code from #40906.
This is the first step in such removal. It removes the RemoteMirror
code for looking up such metadata. It leaves behind:
* Sufficient stubs for LLDB to continue to build. Once LLDB is updated, these stubs can be removed as well.
* The compiler code to emit such metadata. This allows new binaries to still reflect MPEs on older runtimes. This will need to be kept for a transitional period.
If the extension adds conformance to an invertible protocol, it's
confusing for people to also infer conditional requirements on the
generic parameters for those invertible protocols. This came up in the
review of SE-427.
And it is handled compatibly because all existing implementations must
have already implemented it before -- it was an ad-hoc requirement
before Swift 6.0, and now it has become a real requirement - the same as
all the other ad-hoc requirements relying on the Serialization
Requirement
It could be confusing to adopters who were led to believe by the types
that they should "just" implement the sharedUnownedExecutor property,
but insead they have to implement the unownedExecutor on the specific
actor type.
Adding documentation clarify this as well as a simple test that
exercises this explicitly; We seem to have much coverage of main actor,
but not so much of custom executor global actors.
Track the key argument index separately from the generic parameter index when performing the invertible protocol checking in _checkGenericRequirements. This keeps the indexing correct when a non-key argument is followed by a key argument.
rdar://128774651