Instead of requiring the user to disambiguate where an implied
protocol conformance goes---which they really, really don't care
about---just pick an arbitrary-but-deterministic location for the
conformance, which corresponds to the file unit in which the witness
table will be emitted. Fixes rdar://problem/21538899.
Swift SVN r30168
This means that we prefer conformances implied by explicit
conformances (ones that the user wrote) over conformances implied by
synthesized conformances (those that the compiler would
generate). This resolves the ambiguity causing rdar://problem/21007417.
Swift SVN r28880
This may not be the right solution. Even if it is, there are SourceKit tests
that need updating.
This reverts commit r28849 / rdar://problem/21007417.
Swift SVN r28852
Previously, we'd warn on this code:
enum Suit { case Spades, Hearts, Clubs, Diamonds }
extension Suit : Comparable {}
func <(...) {...}
because both Comparable and the synthesized conformance to Hashable imply
a conformance to Equatable. However, that's silly: Suit already has a
synthesized conformance to Equatable associated with the main 'enum'
declaration, not the extension. These compiler-provided conformances are
part of the language and something people rely on, so rank them higher than
conformances implied by conforming to a refined protocol.
rdar://problem/21007417
Swift SVN r28849
(Note that this registry isn't fully enabled yet; it's built so that
we can test it, but has not yet taken over the primary task of
managing conformances from the existing system).
The conformance registry tracks all of the protocols to which a
particular nominal type conforms, including those for which
conformance was explicitly specified, implied by other explicit
conformances, inherited from a superclass, or synthesized by the
implementation.
The conformance registry is a lazily-built data structure designed for
multi-file support (which has been a problematic area for protocol
conformances). It allows one to query for the conformances of a type
to a particular protocol, enumerate all protocols to which a type
conforms, and enumerate all of the conformances that are associated
with a particular declaration context (important to eliminate
duplicated witness tables).
The conformance registry diagnoses conflicts and ambiguities among
different conformances of the same type to the same protocol. There
are three common cases where we'll see a diagnostic:
1) Redundant explicit conformance of a type to a protocol:
protocol P { }
struct X : P { }
extension X : P { } // error: redundant explicit conformance
2) Explicit conformance to a protocol that collides with an inherited
conformance:
protocol P { }
class Super : P { }
class Sub : Super, P { } // error: redundant explicit conformance
3) Ambiguous placement of an implied conformance:
protocol P1 { }
protocol P2 : P1 { }
protocol P3 : P1 { }
struct Y { }
extension Y : P2 { }
extension Y : P3 { } // error: ambiguous implied conformance to 'P1'
This happens when two different explicit conformances (here, P2 and
P3) placed on different declarations (e.g., two extensions, or the
original definition and other extension) both imply the same
conformance (P1), and neither of the explicit conformances imply
each other. We require the user to explicitly specify the ambiguous
conformance to break the ambiguity and associate the witness table
with a specific context.
Swift SVN r26067
