On Rhino, for each file, we now fire all the jsdocCommentFound events in source order, followed by all the symbolFound events in source order. This behavior is consistent with previous versions of JSDoc.
On Node.js, we now fire interleaved jsdocCommentFound and symbolFound events in source order.
Includes a new Rhino .jar file: jsdoc3/rhino@5fbcc2d953
- Do not mark the doclet for the module object as undocumented.
- Track variables (including aliases) within the parent scope, so the members are resolved against the alias instead of the name used in the code.
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.
- Make the parsedType property non-enumerable unless debug mode is enabled.
- Add a more appropriate test case.
- Remove the (incomplete) schema for parsed types.
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.
For consistency with method parameters, this change extends our unfortunate practice of adding type properties to the parent of the `type` object, rather than the object itself.
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.
