This means that we no longer have the invariant that the extendedType always
contains the generic parameters. So we need to fix the assertions/test cases
for it.
If affected declaration is a static or instance memeber (excluding
operators) and failed requirement is declared in other nominal type
or extension, diagnose such problems as `in reference` instead of
claiming that requirement belongs to the member itself.
Extend existing `RequirementFailure` functionality to support
conditional requirement failures. Such fixes are introduced
only if the parent type requirement has been matched successfully.
Resolves: rdar://problem/47871590
If they're printed before being checked, they have little useful content:
just (normal_conformance type=Basic protocol=P1), with no details about their
contents at all.
We don't allow things like
extension Type: P where Param: P {}
extension Type: P where Param: Q {}
or
extension Type: P where Param == Int {}
extension Type: P where Param == Float {}
or
extension Type: P where Param: P {}
extension Type: P where Param == SomethingThatIsntP {}
and the default error message "redundant conformance" message doesn't convey
this very well.
Fixes rdar://problem/36262409.
Many uses of conditional conformance to protocols with super-protocols
are for wrappers, where the conformances to those super-protocols
usually ends up using weaker bounds, such as:
struct MyWrapper<Wrapped: Sequence> {}
extension Wrapped: Sequence {} // Wrapped: Sequence
extension Wrapped: Collection where Wrapped: Collection {} // *
extension Wrapped: BidirectionalCollection where Wrapped: BidirectionalCollection {}
If this code was instead written:
struct MyWrapper<Wrapped: Sequence> {}
extension Wrapped: Sequence {} // Wrapped: Sequence
extension Wrapped: BidirectionalCollection where Wrapped: BidirectionalCollection {}
Inferring a Collection conformance would have to mean
extension Wrapped: Collection where Wrapped: BidirectionalCollection {}
which is unnecessarily strong.
It is a breaking change to change a protocol bound, and so we're
thinking we'd prefer that the compiler didn't magic up that incorrect
conformance. It also only is a small change (and the compiler even
suggests it, with a fixit) to explicitly get the implying behaviour:
declare the conformance explicitly.
extension Wrapped: Collection, BidirectionalCollection where Wrapped: BidirectionalCollection {}
Fixes rdar://problem/36499373.
Previously, the following code would result in different sets of
conditional requirements:
struct RedundancyOrderDependenceGood<T: P1, U> {}
extension RedundancyOrderDependenceGood: P2 where U: P1, T == U {}
struct RedundancyOrderDependenceBad<T, U: P1> {}
extension RedundancyOrderDependenceBad: P2 where T: P1, T == U {}
The T: P1 requirement is redundant: it is implied from U: P1 and T == U,
but just checking it in the signature of the struct isn't sufficient,
the T == U requirement needs to be considered too. This uses a quadratic
algorithm to identify those cases. We don't think the quadratic-ness is
too bad: most cases have relatively few requirements.
Fixes rdar://problem/34944318.
Before this patch, the use of GenericSignature::getSubstitutionMap to
create a substitution map would result in some generic parameters being
completely elided (well, being mapped to concrete types causing a
->castTo<GenericTypeParamType>() to crash). This patch changes that to
just do the reindexing of the type parameters directly, without trying
to be smart with more contextual information (i.e. τ_0_0 -> τ_1_0, even
if there's a τ_0_0 == Int requirement).
Fixes rdar://problem/37291254 and SR-6990.
When forming a specialized protocol conformance, we substitute into the
conditional requirements. Allow this substitution to look into the module
to find conformances, which might be required to accurately represented
the requirements. Otherwise, we can silently end up dropping them.
We should rethink this notion of eagerly substituting conditional
requirements, and consider whether clients should always handle this
substitution. For now, fixes rdar://problem/35837054.
Allow conformance lookup in module context for conditional
Conditional conformances aren't quite ready yet for Swift 4.1, so
introduce the flag `-enable-experimental-conditional-conformances` to
enable conditional conformaces, and an error when one declares a
conditional conformance without specifying the flag.
Add this flag when building the standard library (which will vend
conditional conformances) and to all of the tests that need it.
Fixes rdar://problem/35728337.
Rather than wantonly dropping the conditional requirements when checking
for type erasure, add them in the same way we do for (e.g.) conformance
checking for generics. Fixes rdar://problem/35480860.
Substitute the type arguments of the conforming type into the conditional
requirements of the specialized conformance, so they reflect the specific
requirements of the specialized conformance.
Fixes rdar://problem/34944286.
Rather than storing contextual types in the type witnesses and associated
conformances of NormalProtocolConformance, store only interface types.
@huonw did most of the work here, and @DougGregor patched things up to
complete the change.
