Jazzy puts extension func under wrong class

[SandyChapman]

Steps to reproduce:

1. Add the code below into a Swift project.
2. Run jazzy on the project.
3. Note that one extension is missing altogether and the other has both of the extension funcs defined under it.

import UIKit

extension UITextView {

    public dynamic var fontPointSize : CGFloat {
        get {
            return self.font!.pointSize
        }
        set {
            self.font = UIFont(name: self.font!.fontName, size: newValue)
        }
    }
}

extension UIView {

    public dynamic var cornerRadius: CGFloat {
        get {
            return self.layer.cornerRadius
        }
        set {
            self.layer.cornerRadius = newValue
            self.layer.masksToBounds = cornerRadius > 0
        }
    }
}

Result:

$ jazzy -v
jazzy version: 0.5.0

[SandyChapman]

Just tested out the SourceKitten output run on this project. Looks like it's properly parsing the output so it's looking like the problem is in the site generator portion of jazzy. See attached file.

source-kitten-output-issue-459.txt

[pcantrell]

Looks like the problem is that Sourcekitten is outputting the same USR for both extensions, even though it’s distinguishing the names correctly:

    "key.name" : "UITextView",
    "key.typename" : "UITextView.Type",
    "key.usr" : "c:objc(cs)UIView",

vs

    "key.name" : "UIView",
    "key.typename" : "UIView.Type",
    "key.usr" : "c:objc(cs)UIView",

[SandyChapman]

Oh, good catch. I only noticed that key.name was different.

[jpsim]

Thanks for reporting this! At first glance, it seems like a bug in Apple's SourceKit.

[pcantrell]

Any value in merging based on name+USR as a workaround? Or is that just going to introduce more problems?

[jpsim]

Any value in merging based on name+USR as a workaround? Or is that just going to introduce more problems?

If our integration specs aren't affected by that, I'd say it's safe enough to try.

[jpsim]

@pcantrell fixed this by working around the issue in 0.6.0.