The type that occurs as the thrown error type must conform to the
`Error` protocol. Infer this conformance when the type is a type
parameter in the signature of a function.
An initial implementation of a rework in how
we prevent noncopyable types from being
substituted in places they are not permitted.
Instead of generating a constraint for every
generic parameter in the solver, we produce
real Copyable conformance requirements. This
is much better for our longer-term goal of
supporting `~Copyable` in more places.
Replace the `front()` and `back()` accessors on `InheritedTypes` with dedicated
functions for accessing the start and end source locations of the inheritance
clause. NFC.
Wrap the `InheritedEntry` array available on both `ExtensionDecl` and
`TypeDecl` in a new `InheritedTypes` class. This class will provide shared
conveniences for working with inherited type clauses. NFC.
llvm::SmallSetVector changed semantics
(https://reviews.llvm.org/D152497) resulting in build failures in Swift.
The old semantics allowed usage of types that did not have an
`operator==` because `SmallDenseSet` uses `DenseSetInfo<T>::isEqual` to
determine equality. The new implementation switched to using
`std::find`, which internally uses `operator==`. This type is used
pretty frequently with `swift::Type`, which intentionally deletes
`operator==` as it is not the canonical type and therefore cannot be
compared in normal circumstances.
This patch adds a new type-alias to the Swift namespace that provides
the old semantic behavior for `SmallSetVector`. I've also gone through
and replaced usages of `llvm::SmallSetVector` with the
`Swift::SmallSetVector` in places where we're storing a type that
doesn't implement or explicitly deletes `operator==`. The changes to
`llvm::SmallSetVector` should improve compile-time performance, so I
left the `llvm::SmallSetVector` where possible.
getInheritedProtocols() skips type resolution and directly resolves
TypeReprs to TypeDecls.
On the other hand, when building a protocol requirement signature,
we use type resolution to resolve inheritance clause entries so
that we can properly support parameterized protocol types, and
protocol compositions that contain classes.
Since a TypeRepr with an invalid sub-component resolves to an
ErrorType, this meant that in invalid code, the first list of
protocols might contain protocols that don't appear in the second.
This broke rewrite system invariants. Fix this by checking if
type resolution failed when building the requirement signature of
a protocol, and if so, also look at getInheritedProtocols().
Fixes https://github.com/apple/swift/issues/61020.
RequirementSignatureRequest
=> TypeAliasRequirementsRequest
=> isConstrainedExtension()
=> GenericSignatureRequest
=> RequirementSignatureRequest
Instead, use getTrailingWhereClause() as an approximation of
isConstrainedExtension().
Fixes rdar://problem/97236936.
Every protocol gets an 'identity conformance' rule [P].[P] => [P].
A trivially-stated circularity is always redundant because of this
rule, and we diagnose circular inheritance elsewhere as a hard
error, so just add a special case to skip adding such a rule here
to avoid the useless warning on top of the existing error.
We want to allow this for all conformance requirements written in protocols
or the `where` clause of protocol extensions.
Fixes rdar://problem/91304291.
A protocol typealias 'typealias T = X' introduces a same-type requirement
'Self.T == Self.X'. However the right hand side of the requirement was
wrapped in a sugared TypeAliasType.
This meant if the requirement surfaced in a redundancy diagnostic, it
would print as 'Self.T == Self.T'. It could also trigger a request cycle
via isInterestingTypealias() in DiagnosticEngine.cpp.
