Mention the type, the requirement, and the extension in the error that
follows. In editor mode, try to insert stubs for the missing requirement
as well so the user isn't just left with a pile of unactionable errors.
Currently it's possible to have a type conflict between different
requirements deduced as the same type which leads to incorrect
diagnostics. To mitigate that let's adjust how "fixed" requirements
are stored - instead of using resolved type for the left-hand side,
let's use originating generic parameter type.
Solutions passed to `diagnoseAmbiguityWithFixes` aren't filtered
so we need to remove all of the solutions with the score worse
than overall "best". Also logic has to account for some fixes being
"warnings".
* [TypeChecker] Enclosing stubs protocol note within editor mode
* [test] Removing note from test where there is no -diagnostics-editor-mode flag
* Formatting modified code
* [tests] Fixing tests under validation-tests
Under non-editor mode, the fixit for inserting protocol stubs is associated with a note
pointing to the missing protocol member declaration which could stay in a separate file from
the conforming type, leading to the behavior of rdar://51534405. This change checks if
the fixit is in a separate file and issues another note to carry the fixit if so.
rdar://51534405
If a struct/enum cannot have Equatable/Hashable conformance automatically synthesized because a member's type is not Equatable/Hashable, add a note to the existing 'does not conform' diagnostic pointing out the type that blocked synthesis.
If a conformance to a protocol is implied by several other
conformances (i.e. protocol P: Equatable {} and protocol Q: Equatable {} and a
type declares conformance to both P and Q), we should choose a source that's in
the same file as the type, if we can, because automatic synthesis of
conformances (for Equatable, Hashable, etc.) only works in that case.
Fixes rdar://problem/41852654.
'private' properties can't be accessed in extensions in Swift 3, so synthesizing
a conformance that reads from such things is going to be incorrect in an
extension.
This works for all protocols except for Decodable on non-final classes, because
the init requirement has to be 'required' and thus in the type's declaration.
Fixes most of https://bugs.swift.org/browse/SR-6803.
This converts the instances of the pattern for which we have a proper
substitution in lit. This will make it easier to replace it
appropriately with Windows equivalents.
Instead of warning about an unused result of a call to an implicit
function '__derived_enum_equals' or '__derived_struct_equals' use its
user-facing name '=='.
