When an interface is a) defined as an ES2015 class and b) assigned to a variable, JSDoc sometimes used the wrong `longname` and `memberof` for members of the interface (specifically, for instance properties).
The root cause was that we weren't resolving `this` correctly within this type of interface. As a result, if you added a JSDoc comment to something like `this.foo = 'bar'`, the doclet for `this.foo` had the wrong `longname` and `memberof`.
Fixing that issue uncovered another issue: When we merged the constructor's doclet with the interface's doclet, we preferred the constructor's doclet. However, the constructor's doclet used the wrong `kind` in this case; we already had code to fix up the `longname` and `memberof` of the combined doclet, but not the `kind`. The fix was to prefer the interface's doclet for all properties.
Catharsis caches parse results by default; if you parse the same type expression twice, with the same options, you get the same object each time.
When the user passes the `--debug` flag, we expose the parsed type for each parameter as an enumerable property of the doclet. If two parameters used the same type expression, the resulting doclet could contain a circular reference.
This change disables the Catharsis cache, so that Catharsis returns a new object for each parsed type, which prevents circular references. As a result, this change fixes an issue with the `-X` flag, and with some JSDoc templates.
Previously, when we combined doclets, we copied the `undocumented` property if it was set to `true`. That caused the combined doclet to have this property set to `true`, although it shouldn't have. As a result, the template discarded the doclet.
The solution is to simply ignore this property when combining doclets.
Also includes related cleanup for clarity.
When this option is set to `true`, the `{@link}`, `{@linkcode}`, and `{@linkplain}` tags will use the short name, not the longname, as the link text. For example, `{@link foo.bar.baz}` will result in the link text `baz`.
This option has no effect when link text is provided as part of the tag (for example, `{@link foo.bar.baz My link text here}`).
As part of this change, I also simplified many of the tests for the `resolveLinks` method.
The `@override` tag no longer causes all other doclet properties to be ignored. Instead, the doclet will keep its own properties and inherit any missing properties from the parent class or interface.