Suspected "conflicting type declarations"

[SimplyDanny]

I found a few issues mentioning this problem as well, yet they are more focused on the documentation aspect of this warning printed by Jazzy:

Found conflicting type declarations with the same name, which may indicate a build issue or a bug in Jazzy: instance method print(), instance method print()

The code causing this looks like:

/// A protocol
public protocol Printable {
    /// A method
    func print()
}

public extension Printable where Self: CustomStringConvertible {
   func print() {
       Swift.print(self)
   }
}

Other than that, Jazzy reports 100% documentation coverage with 0 undocumented symbols and included 4 public or open symbols. So it seems to be happy with the fact that the print implementation in the extension is undocumented even though it has discovered it. It also doesn't create any documentation for it.

Now, if I document the print implementation like

public extension Printable where Self: CustomStringConvertible {
   /// A method implementation
   func print() {
       Swift.print(self)
   }
}

the warning doesn't appear in the output and the method get its own section in the documentation.

So the documentation side seems to be okay and reasonable. However, the warning is still there in the first case. This is what I want to address in this report.

[johnfairh]

Well! The problem appears to be that, when a doc comment is 'inherited' for a default implementation like this from the protocol member, SourceKit accidentally 'inherits' the USR as well, reporting the protocol member USR s:10BreakJazzy9PrintableP5printyyF for the default implementation instead of its own USR s:10BreakJazzy9PrintablePAAs23CustomStringConvertibleRzrlE5printyyF --- you noticed the problem vanished when commenting the extension, it also goes away if you delete the comment from the proto member.

So, jazzy is correctly reporting two different things in the same scope that claim to be each other.

The user workaround is clear: add a doc comment to the default implementation.

I think we can work around in jazzy and make this work properly by adding in the key.typename to the not-so-USR which is luckily not messed up by this bug -- <Self where Self : Printable, Self : CustomStringConvertible> (Self) -> () -> () vs. <Self where Self : Printable> (Self) -> () -> (), will need to see if it breaks anything else.