Swift 3 allowed a class to explicitly conform to AnyObject, although
it was meaningless. Recent AnyObject-related changes started rejecting
such conformances as ill-formed; allow them with a warning + Fix-It in
Swift 3 compatibility mode.
When an extension introduces a conformance that already exists, the
type checker will reject the conformance and then ignore it. In cases
where the original conformance is in the same module as the type or
protocol (but the new, redundant conformance is in some other module),
downgrade this error to a warning. This helps with library-evolution
cases where a library omitted a particular conformance for one of its
own types/protocols in a previous version, then introduces it in a new
version.
The specific driver for this is the conformance of String to
Collection, which affects source compatibility. Fixes
rdar://problem/31104415.
This reverts part of #4038 which made the compiler consider it to be an `Explicit` conformance, breaking source code that was accepted in Swift 3.0 which declared a raw type as well as explicit conformance to `RawRepresentable` (reported as rdar://problem/30386658). While I'm here, a couple of spot fixes:
- Ensure an enum's raw value exprs are type-checked before checking conformances of any of its extensions, since the RawRepresentable conformance derivation will blow up if the raw value exprs haven't been checked. Fixes an order dependency issue if `extension Foo: RawRepresentable {}` gets checked before `enum Foo: Int { ... }`.
- Don't display the custom `enum_declares_rawrep_with_raw_type` diagnostic if the source location for the enum's inheritance clause is invalid, so that we don't emit a dislocated diagnostic.
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
