We've had a load-bearing optimization that avoids rebuilding
the generic signature of the protocol extension to avoid a
cycle involving a typealias in the extension that's mentioned
as a requirement in the protocol, for example:
```
public protocol P3 {
associatedtype A
}
public protocol P4: P3 where A == B {}
extension P4 {
public typealias B = String
}
```
What was happening is that we're inside a
StructuralRequirementsRequest, so we're performing TypeResolution
in the Structural stage. When we encounter this typealias that's
within a protocol extension, we'd end up accidentally requesting
the interface type of that alias through
`TypeChecker::substMemberTypeWithBase`
(via `aliasDecl->getUnderlyingType()`).
What we should do instead is call `aliasDecl->getStructuralType()`
and skip the substitution during that stage.
There happened to already be code doing this, but it was only
kicking in if the DeclContext `isa<ProtocolDecl>`, which excludes
extensions of a protocol. I see no reason why extensions of a
protocol should be excluded, so I assume it was unintentional.
Thus, the fix boils down to using `DeclContext::getSelfProtocolDecl`
which does include extensions of protocols. With this fix, the
optimization is no longer load-bearing on the example above.
See the history of this hack in f747121080
or rdar://problem/129540617
Make sure we only ever type-check the `do` body of a `do-catch`
statement when lazily type-checking the bound error type, which we can
do for completion.
rdar://164481242
For semantic functionality the API decl is the more useful thing to
mangle, and redeclaration checking ensures we can't end up with
conflicts. This ensures we're able to perform a name lookup for the
decl based on its USR without having to maintain a separate lookup
table for ABI names.
Clients should be able to handle closures without a valid `in`
SourceLoc, let's avoid setting it to a recovery location. This avoids
crashing in cases where we set an `in` loc that's after the closure's
end loc.
Tuple extensions are still an experimental feature, but we have a
number of crashers in the repo for them because we still use their
type-checker machinery even when disabled. Change the logic here such
that we reject them early in extension binding when the feature is
disabled. This will ensure we address the crashers before productizing.
If we failed to construct a rewrite system for a protocol, either because
the Knuth-Bendix algorithm failed or because of a request cycle while
resolving requirements, we would end up in a situation where the resulting
rewrite system didn't include all conformance requirements and associated
types, so name lookup would find declarations whose interface types are
not valid type parameters.
Fix this by propagating failure better and just doing nothing in
getReducedTypeParameter().
Fixes rdar://147277543.
Move the logic from `FailureDiagnostic::resolveType` into
`Solution::simplifyType` to allow completion to use it too. While
here, also handle cases where the placeholder is from a different
member of the equivalence class to the generic parameter.
In preparation for removing UnresolvedType in favor of ErrorType,
start printing ErrorType as `_` unless we've enabled debug printing.
`<<error type>>` should never be presented to the user, instead `_`
now just consistently means "unknown type".
We still need to solve a branch with a ReturnStmt to avoid leaving
the contextual result type unbound. This isn't currently legal anyway,
so isn't likely to come up often in practice, but make sure we can
still solve.
This is useful for ArrowExpr when the sub-expressions aren't valid
TypeExprs. Rather than throwing away the AST, attach it to the
ErrorTypeRepr to ensure we can still type-check it. This ensures
semantic functionality still works correctly, and fixes a crash where
we'd stop visiting an invalid binding pattern, losing track of the
nested VarDecl.
