Sema: Fix regression with 'Failure' type witness inference hack

We have a special hack to infer the 'Failure' type witness in
'AsyncIteratorProtocol' by considering the type of 'next()'
witness.

In eaf06eae0e I added a check to
fix some assertions that could happen if 'next()' was witnessed
by a declaration in a protocol extension or superclass, which
has a different generic signature.

However my check was too narrow, because it also prohibited
this form of inference when 'next()' was in a different
extension of the same nominal type.

Allow this again.

Fixes https://github.com/swiftlang/swift/issues/79367.
Fixes rdar://problem/145341658.
This commit is contained in:
Slava Pestov
2025-04-03 12:24:17 -04:00
parent ff14828c7f
commit 7c7caa2088
2 changed files with 20 additions and 1 deletions

View File

@@ -2496,7 +2496,11 @@ AssociatedTypeInference::computeFailureTypeWitness(
if (!isAsyncIteratorProtocolNext(witness.first))
continue;
if (!witness.second || witness.second->getDeclContext() != dc)
// Different extensions of the same nominal are OK, but if the witness is in
// a protocol extension or a superclass or something, give up.
if (!witness.second ||
witness.second->getDeclContext()->getSelfNominalTypeDecl()
!= dc->getSelfNominalTypeDecl())
continue;
if (auto witnessFunc = dyn_cast<AbstractFunctionDecl>(witness.second)) {

View File

@@ -0,0 +1,15 @@
// RUN: %target-typecheck-verify-swift
// https://github.com/swiftlang/swift/issues/79367
// 'Failure' type witness inference should still take place when
// the 'next()' witness is in a different extension than the
// conformance.
struct AsyncIteratorImpl<Element>: AsyncIteratorProtocol {}
extension AsyncIteratorImpl {
func next() async throws -> Element? {
fatalError()
}
}