Fixes a bizarre bug that caused us to assign the wrong name to object properties, apparently because the node ID was not defined at the appropriate time.
We ignore other types based on these assumptions:
1) It doesn't make sense to show variable identifiers, which may refer to (for example) module-private values that should not be documented.
2) If we tried to capture objects and arrays, we would have to iterate over them to see if they contain any variable identifiers, which would be a pain (and potentially confusing: "Why do some objects appear in the docs but not others?")
3) Most developers will not define complex default values in a function definition.
4) In many cases, object and array default values will be `{}` and `[]`, respectively, and usually those don't merit documentation.
As part of this commit, we automatically flag rest parameters as repeatable, even if the JSDoc comment doesn't identify the parameter as repeatable. As a result, it's difficult to document a rest parameter as though it were a normal parameter (should you want to do that for some reason). I may revert this piece if it generates complaints.
class being exported within the module -- this has actually shown that
the doclets produced are probably correct, and that the bug is likely to
be within the template.
The issue in brief: Within an object literal, if a standalone comment was followed by a commented symbol, the symbol's comment would not be attached correctly.
The fix essentially reverts the changes for #565, which are no longer needed thanks to 50cd99fa2fca753fcf7c9ec3ecf70afd47168e94.
The fix also corrects the order in which we walk a MemberExpression's child nodes. Without this correction, comments would not be attached correctly inside CallExpression nodes.
There were three separate problems here:
1. The visitor called `trackVars` at the wrong time for `AssignmentExpression` and `VariableDeclarator` nodes, which prevented JSDoc from setting the `funcscope` property correctly.
2. The `funcscope` property was being added to `VariableDeclarator` nodes. It should only be added to `AssignmentExpression` nodes.
3. We were trying to resolve the variable name `____` in `AssignmentExpression` nodes. This is a special value we add to the source code so that the `lends` tag will work, and it should never be resolved against the enclosing scope.
The previous, buggy behavior looked reasonable in most cases, but it didn't work for closures that contain multiple `lends` tags.
