Parse jsdoc `@param` type literals #17352

sandersn · 2017-07-21T21:55:48Z

Now Typescript supports the creation of anonymous types using successive @param lines in JSDoc:

/**
 * @param {object} o - has a string and a number
 * @param {string} o.s - the string
 * @param {number} o.n - the number
 */
function f(o) { return o.s.length + o.n; }

This is equivalent to the Typescript syntax { s: string, n: number }, but it allows per-property documentation, even for types that only need to be used in one place. (@typedef can be used for reusable types.)

If the type of the initial @param is {object[]}, then the resulting type is an array of the specified anonymous type:

/**
 * @param {Object[]} os - has a string and a number
 * @param {string} os[].s - the string
 * @param {number} os[].n - the number
 */
function f(os) { return os[0].s; }

Finally, nested anonymous types can be created by nesting the pattern:

/**
 * @param {Object[]} os - has a string and a number
 * @param {string} os[].s - the string
 * @param {object} os[].nested - it's nested because of the object type
 * @param {number} os[].nested.length - it's a number
 */
function f(os) { return os[0].nested.length; }

Implementation notes:

I refactored JSDocParameterTag and JSDocPropertyTag to JSDocPropertyLikeTag and modified its parsing to be more succinct. These changes make the overall change easier to read but are not strictly required.
parseJSDocEntityName accepts postfix[] as in os[].nested.length, but it doesn't check that usages are correct. Such checking would be easy to add but tedious and low-value.
@typedef doesn't support nested @property tags, but does support object[] types. This is mostly a practical decision, backed up by the fact that usejsdoc.org doesn't document nested types for @typedef.

Fixes #11597

@param

Now Typescript supports the creation of anonymous types using successive `@param` lines in JSDoc: ```js /** * @param {object} o - has a string and a number * @param {string} o.s - the string * @param {number} o.n - the number */ function f(o) { return o.s.length + o.n; } ``` This is equivalent to the Typescript syntax `{ s: string, n: number }`, but it allows per-property documentation, even for types that only need to be used in one place. (`@typedef` can be used for reusable types.) If the type of the initial `@param` is `{object[]}`, then the resulting type is an array of the specified anonymous type: ```js /** * @param {Object[]} os - has a string and a number * @param {string} os[].s - the string * @param {number} os[].n - the number */ function f(os) { return os[0].s; } ``` Finally, nested anonymous types can be created by nesting the pattern: ```js /** * @param {Object[]} os - has a string and a number * @param {string} os[].s - the string * @param {object} os[].nested - it's nested because of the object type * @param {number} os[].nested.length - it's a number */ function f(os) { return os[0].nested.length; } ``` Implementation notes: 1. I refactored JSDocParameterTag and JSDocPropertyTag to JSDocPropertyLikeTag and modified its parsing to be more succinct. These changes make the overall change easier to read but are not strictly required. 2. parseJSDocEntityName accepts postfix[] as in `os[].nested.length`, but it doesn't check that usages are correct. Such checking would be easy to add but tedious and low-value. 3. `@typedef` doesn't support nested `@property` tags, but does support `object[]` types. This is mostly a practical decision, backed up by the fact that usejsdoc.org doesn't document nested types for `@typedef`.

weswigham

Generally agreeable; there are some refactorings of how jsdoc params and properties are stored which I like. Only thing I'd mention is that there are quite a few ts.isIdentifier which would normally be just isIdentifier (unless there's a reason not to).

The whole name first/name second thing feels a little hairy to deal with; I almost feel it would be neater to handle if each variant were a different SyntaxKind. (I mean, I guess they do parse differently, so it'd make sense) Up to you, though. This feels better than how it was handled before, anyway.

ghost · 2017-07-24T20:57:01Z

src/compiler/utilities.ts

@@ -1553,6 +1553,10 @@ namespace ts {

    /** Does the opposite of `getJSDocParameterTags`: given a JSDoc parameter, finds the parameter corresponding to it. */
    export function getParameterFromJSDoc(node: JSDocParameterTag): ParameterDeclaration | undefined {


See the (sole) use of this function -- at x in @param obj.x we should return the symbol for x. Add a find-all-references test.

/** * @param obj.[|x|] */ function f(obj) { obj.[|x|]; }

ghost · 2017-07-24T21:02:31Z

src/compiler/binder.ts

-                    return declareSymbolAndAddToSymbolTable(node as JSDocPropertyTag,
-                        (node as JSDocPropertyTag).isBracketed || ((node as JSDocPropertyTag).typeExpression && (node as JSDocPropertyTag).typeExpression.type.kind === SyntaxKind.JSDocOptionalType) ?
+                    return declareSymbolAndAddToSymbolTable(node as JSDocPropertyLikeTag,
+                        (node as JSDocPropertyLikeTag).isBracketed || ((node as JSDocPropertyLikeTag).typeExpression && (node as JSDocPropertyLikeTag).typeExpression.type.kind === SyntaxKind.JSDocOptionalType) ?


This expression is too large.

const prop = node as JSDocPropertyLikeTag; const flags = prop.isBracketed || prop.typeExpression && prop.typeExpression.type.kind === SyntaxKind.JSDocOptionalType ? SymbolFlags.Property | SymbolFlags.Optional : SymbolFlags.Property; return declareSymbolAndAddToSymbolTable(prop, flags, SymbolFlags.PropertyExcludes);

Also, typeExpression is declared non-optional, but here we test for its presence.

ghost · 2017-07-24T21:54:15Z

src/compiler/checker.ts

-                    declaration = getDeclarationOfKind<TypeAliasDeclaration>(symbol, SyntaxKind.TypeAliasDeclaration);
-                    type = getTypeFromTypeNode(declaration.type);
-                }
+                const declaration = getDeclarationOfKind<JSDocTypedefTag>(symbol, SyntaxKind.JSDocTypedefTag) ||


getDeclarationOfKind hides a loop, so this loops twice. Could add a version of that function that takes two kinds.

I'll just use findDeclaration which takes a predicate.

I was going to delete that function in #17380 since it's equivalent to just find(symbol.declarations, ...) -- this would be one of only 2 uses.

ghost · 2017-07-24T21:59:05Z

src/compiler/types.ts

        typeExpression: JSDocTypeExpression;
+        /** Whether the property name came before the type -- non-standard for JSDoc, but Typescript-like */
+        isParameterNameFirst: boolean;


If this applies to more than just parameters, it should be renamed.

ghost · 2017-07-24T22:01:16Z

src/compiler/parser.ts

-                    visitNode(cbNode, (<JSDocParameterTag>node).typeExpression) ||
-                    visitNode(cbNode, (<JSDocParameterTag>node).postParameterName);
+            case SyntaxKind.JSDocPropertyTag:
+                if ((node as JSDocPropertyLikeTag).isParameterNameFirst) {


Maybe this should wait for a separate PR, but I would much prefer to see code like:

const { isParameterNameFirst, fullName, typeExpression } = node as JSDocPropertyLikeTag;

in all of these cases, instead of repeated casting.

I will make the change here if you are willing to review it! 😅 I'll put it in a separate commit at the end which might make it easier.

Please make a separate PR as that would be a huge diff.

ghost · 2017-07-24T22:04:04Z

src/compiler/parser.ts

-                    visitNode(cbNode, (<JSDocTypedefTag>node).fullName) ||
-                    visitNode(cbNode, (<JSDocTypedefTag>node).name) ||
-                    visitNode(cbNode, (<JSDocTypedefTag>node).jsDocTypeLiteral);
+                if ((node as JSDocTypedefTag).typeExpression &&


It looks like name is a pointer to a node within fullName. So it would be visited twice if we were recursively calling forEachChild.

Nice catch! I added fullName later and didn't notice that name needed to be removed.

ghost · 2017-07-25T16:38:51Z

src/compiler/parser.ts

                        typeExpression = tryParseTypeExpression();
                    }

-                    const result = shouldParseParamTag ?
+                    const result: JSDocPropertyLikeTag = target ?


Since target is now an enum, use an explicit comparison instead of treating it like a boolean.

ghost · 2017-07-25T16:40:50Z

src/compiler/parser.ts

                }

-                function parseParameterOrPropertyTag(atToken: AtToken, tagName: Identifier, shouldParseParamTag: boolean): JSDocPropertyTag | JSDocParameterTag {
+                function isObjectOrObjectArrayTypeReference(node: TypeNode): boolean {
+                    return node.kind === SyntaxKind.ObjectKeyword ||


Use a switch.

isTypeReferenceNode just tests the syntax kind, so just make that a switch case and have default: return false;.

ghost · 2017-07-25T16:43:53Z

src/compiler/parser.ts

                    skipWhitespace();

-                    let preName: Identifier, postName: Identifier;
+                    let preName: EntityName, postName: EntityName;


It no longer makes sense to have separate preName and postName variables. Just create isParameterNameFirst directly.

ghost · 2017-07-25T16:46:58Z

src/compiler/parser.ts


-                function tryParseChildTag(parentTag: JSDocTypeLiteral): boolean {
+                function parseChildParameterOrPropertyTag(target: PropertyLikeParse.Property): JSDocTypeTag | JSDocPropertyTag | false;


Since there are only 2 possible targets, maybe there should just be 2 different functions parseChildParmeterTag and parseChildPropertyTag that both use parseChildParameterOrPropertyTagCommon?

I think a more likely refactoring would be to pass 1 of 2 different tryParseChildTag functions instead of the target enum. But the target enum pattern is also used with parseParameterOrPropertyTag, and it's as easy to read and (probably?) as fast to run, so I think I'll keep it this way.

ghost · 2017-07-25T16:49:13Z

src/compiler/parser.ts

+                                jsdocTypeLiteral = <JSDocTypeLiteral>createNode(SyntaxKind.JSDocTypeLiteral, start);
+                                jsdocTypeLiteral.jsDocPropertyTags = [] as MutableNodeArray<JSDocPropertyTag>;
+                            }
+                            (jsdocTypeLiteral.jsDocPropertyTags as MutableNodeArray<JSDocPropertyTag>).push(child as JSDocPropertyTag);


You could just the create the mutable array locally and assign to jsdocTypeLiteralat the end. That way you avoid casting an already-created object to mutable.
This loop could probably be its own function parseParameterTags returning NodeArray<JSDocPropertyTag> | undefined.
Also, you don't appear to be setting the position on the array -- if you don't want to do that, just declare it as an ReadonlyArray and not a NodeArray.
Also, what's with the cast on child? You passed in PropertyLikeParse.Parameter so it's surprising to see an assertion that what you got back isn't a parameter.

I don't know a correct position to set on the child array because I don't know what would use it. I don't think I can make it a ReadonlyArray though, because forEachChild expects to iterate over a NodeArray. For now I'll still create a NodeArray with no position.

You could just use a for loop instead of calling cbNodes, which does require a NodeArray, meaning users might be expecting it to have a position.

Sure. Done.

ghost · 2017-07-25T16:54:11Z

src/compiler/parser.ts

-                    result.postParameterName = postName;
-                    result.name = postName || preName;
+                    if (typeExpression) {
+                        result.type = typeExpression.type;


Isn't this redundant? Why do we have both typeExpression and type?

I wasn't sure how much like a real VariableDeclaration JSDocPropertyLikeTag should become and ended up halfway there. It turns out to be easier to continue special-casing it in getTypeOfVariableOrParameterOrProperty instead of having it become a full-fledged declaration. I dropped type in favour of typeExpression.

ghost · 2017-07-25T16:55:17Z

src/compiler/parser.ts

+                        result.type = typeExpression.type;
+                    }
+                    result.fullName = postName || preName;
+                    result.name = ts.isIdentifier(result.fullName) ? result.fullName : result.fullName.right;


This is also redundant, I would just make this a function of the node and not a property.

This was another convenience shim. I turned name into fullName and pushed the isIdentifier check into getNameOfDeclaration.

ghost · 2017-07-25T16:55:46Z

src/compiler/parser.ts

                    result.isBracketed = isBracketed;
                    return finishNode(result);
+


Nit: line before a closing bracket doesn't really accomplish anything -- nothing to separate that isn't already separated by the closing bracket.

ghost · 2017-07-25T17:00:12Z

src/compiler/parser.ts

+                            }
+                            if (child.kind === SyntaxKind.JSDocTypeTag) {
+                                if (alreadyHasTypeTag) {
+                                    break;


What happens to child in this case? We just drop it with no syntax error?

I think this comment is still unaddressed?

Yes. It happens in this case:

/** * @typedef Name * @type {string} * @type {Oops} - this is dropped and we stop parsing the @typedef */

This would be a grammar error if we did more thorough checking of jsdoc structure in the checker (along with a lot of other incorrect-but-allowed jsdoc). We don't, which is OK relative to what we used to provide. We should probably improve in the future if jsdoc becomes the source of types for significant, typed codebases.

OK, added #17442.

ghost · 2017-07-25T17:01:05Z

src/compiler/parser.ts

+                            }
+                            else {
+                                if (!jsdocTypeLiteral.jsDocPropertyTags) {
+                                    jsdocTypeLiteral.jsDocPropertyTags = [] as MutableNodeArray<JSDocPropertyTag>;


See earlier comment on casting to MutableNodeArray.

ghost · 2017-07-25T17:02:02Z

src/compiler/parser.ts

-                        if (!typedefTag.jsDocTypeLiteral) {
-                            typedefTag.jsDocTypeLiteral = <JSDocTypeLiteral>typeExpression.type;
+                        if (jsdocTypeLiteral) {
+                            if (typeExpression && typeExpression.type.kind === SyntaxKind.ArrayType) {


What are our performance guidelines on optionally vs unconditionally assigning to a property?

I thought the standard for booleans was to declare them as b?: boolean and only assign them when needed. What difference in performance could arise? Conditional assignment saves space (but how much I don't know) versus unconditional assignment, which could be better for [de]optimisation. @rbuckton do you have an opinion?

ghost · 2017-07-25T17:03:19Z

src/compiler/parser.ts

@@ -6647,8 +6671,61 @@ namespace ts {
                    }
                }

+                function textsEqual(parent: EntityName, name: EntityName): boolean {


Nit: would just name these variables a and b since they don't really depend on a parent-child context.

ghost · 2017-07-25T17:06:41Z

src/compiler/parser.ts

+                    while (token() !== SyntaxKind.EndOfFileToken) {
+                        nextJSDocToken();
+                        switch (token()) {
+                        case SyntaxKind.AtToken:


Nit: indent switch body

ghost · 2017-07-25T17:10:15Z

src/compiler/parser.ts

+                                const child = tryParseChildTag(target);
+                                if (child && child.kind === SyntaxKind.JSDocParameterTag &&
+                                    (ts.isIdentifier(child.fullName) || !textsEqual(fullName, child.fullName.left))) {
+                                    break;


Should this be break loop? It looks like the way it is currently, it goes all the way to the end of the file, when we could stop the moment we see something that isn't an @param tag with the correct name.

This function is always called from in a speculative context, so I can actually just return false.

ghost · 2017-07-25T17:11:09Z

src/compiler/parser.ts

+                            break;
+                        }
+                    }
+                    scanner.setTextPos(resumePos);


Do we have an established pattern for re-setting the scanner? What if scanner has some other state that this doesn't reset?

Yep, this is left over from the old scanChildTags that faked its own speculative parsing. Removed.

ghost · 2017-07-25T17:11:49Z

src/compiler/parser.ts

+                    scanner.setTextPos(resumePos);
+                }
+
+                function tryParseChildTag(target: PropertyLikeParse, alreadyHasTypeTag?: boolean): JSDocTypeTag | JSDocPropertyTag | JSDocParameterTag | false {


This is only called in one place, and alreadyHasTypeTag is never provided.

Oops, I moved that up a couple of levels and forgot to remove it here.

ghost · 2017-07-25T17:13:10Z

src/compiler/parser.ts

-                            // Error parsing property tag
-                            return false;
+                            return target === PropertyLikeParse.Property && parseParameterOrPropertyTag(atToken, tagName, target);
+                        case "arg":


Is the information about what tag name was used available in the AST? That might be useful for linting.

Yes, JSDocTag.tagName: Identifier, so it looks like it's preserved on all JSDocTags.

A more useful lint rule would be to look for mismatched typedef/param and param/property nestings, since the compiler currently ignores them:

/** * @typedef {object} x * @param {string} x.a - WRONG! (but ignored by the compiler) * * @param {object} y * @property {string} y.a - WRONG! (but ignored by the compiler) */

ghost · 2017-07-25T17:14:16Z

src/compiler/parser.ts

@@ -6728,6 +6794,26 @@ namespace ts {
                    return currentToken = scanner.scanJSDocToken();
                }

+                function parseJSDocEntityName(createIfMissing = false): EntityName {


This is only called in one place, and createIfMissing is always true.

This could use:

function createQualifiedName(entity: EntityName, name: Identifier): QualifiedName { const node = createNode(SyntaxKind.QualifiedName, entity.pos) as QualifiedName; node.left = entity; node.right = name; return finishNode(node); }

And you can re-use createQualifiedName in parseEntityName. (parseJSDocEntityName should probably be near parseEntityName since they are similar.)

Done. I thought about merging parseEntityName and parseJSDocEntityName, but they both worry about ad-hoc jsdoc-related things, plus they call into different identifier parsers which do the same.

ghost · 2017-07-25T17:59:21Z

src/services/classifier.ts

-                    pushClassification(tag.postParameterName.pos, tag.postParameterName.end - tag.postParameterName.pos, ClassificationType.parameterName);
-                    pos = tag.postParameterName.end;
+                if (!tag.isParameterNameFirst) {
+                    pushCommentRange(pos, tag.name.pos - pos);


These two if blocks are the same, so use this helper:

function pushName(name: Identifier) { pushCommentRange(pos, name.pos - pos); pushClassification(name.pos, name.end - name.pos, ClassificationType.parameterName); pos = name.end; }

Don't know why this shows as outdated, it still seems relevant.

ghost · 2017-07-25T18:01:04Z

src/services/jsDoc.ts

@@ -120,7 +120,7 @@ namespace ts.JsDoc {
    }

    export function getJSDocParameterNameCompletions(tag: JSDocParameterTag): CompletionEntry[] {
-        const nameThusFar = unescapeLeadingUnderscores(tag.name.text);
+        const nameThusFar = isIdentifier(tag.fullName) ? unescapeLeadingUnderscores(tag.name.text) : undefined;


I think we should bail out immediately if it's not an identifier, instead of continuing with an undefined nameThusFar.

Done. I returned emptyArray instead of undefined. I'm not sure whether that's correct.

Should be fine.

I'll take a look at Wesley's next and see if those require any changes.

sandersn

Responses to review comments

sandersn · 2017-07-25T16:55:53Z

src/compiler/binder.ts

-                    return declareSymbolAndAddToSymbolTable(node as JSDocPropertyTag,
-                        (node as JSDocPropertyTag).isBracketed || ((node as JSDocPropertyTag).typeExpression && (node as JSDocPropertyTag).typeExpression.type.kind === SyntaxKind.JSDocOptionalType) ?
+                    return declareSymbolAndAddToSymbolTable(node as JSDocPropertyLikeTag,
+                        (node as JSDocPropertyLikeTag).isBracketed || ((node as JSDocPropertyLikeTag).typeExpression && (node as JSDocPropertyLikeTag).typeExpression.type.kind === SyntaxKind.JSDocOptionalType) ?


sandersn · 2017-07-25T16:56:26Z

src/compiler/parser.ts

-                    visitNode(cbNode, (<JSDocTypedefTag>node).fullName) ||
-                    visitNode(cbNode, (<JSDocTypedefTag>node).name) ||
-                    visitNode(cbNode, (<JSDocTypedefTag>node).jsDocTypeLiteral);
+                if ((node as JSDocTypedefTag).typeExpression &&


sandersn · 2017-07-25T16:57:35Z

src/compiler/types.ts

        typeExpression: JSDocTypeExpression;
+        /** Whether the property name came before the type -- non-standard for JSDoc, but Typescript-like */
+        isParameterNameFirst: boolean;


sandersn · 2017-07-25T21:09:32Z

src/compiler/utilities.ts

@@ -1553,6 +1553,10 @@ namespace ts {

    /** Does the opposite of `getJSDocParameterTags`: given a JSDoc parameter, finds the parameter corresponding to it. */
    export function getParameterFromJSDoc(node: JSDocParameterTag): ParameterDeclaration | undefined {


sandersn · 2017-07-25T21:13:26Z

src/compiler/checker.ts

-                    declaration = getDeclarationOfKind<TypeAliasDeclaration>(symbol, SyntaxKind.TypeAliasDeclaration);
-                    type = getTypeFromTypeNode(declaration.type);
-                }
+                const declaration = getDeclarationOfKind<JSDocTypedefTag>(symbol, SyntaxKind.JSDocTypedefTag) ||


I'll just use findDeclaration which takes a predicate.

sandersn · 2017-07-25T21:21:51Z

@weswigham

The parser defines its own isIdentifier which operates while parsing an identifier, unlike the normal ts.isIdentifier.
I kind of like the idea of having different syntax kinds for (1) normal @param (2) type literal @param (3) non-standard @param, but I'm not sure it's worth the effort. I'll think about it and maybe include it in this PR and maybe not.

ghost · 2017-07-26T18:17:56Z

src/compiler/parser.ts

+                    let seenAsterisk = false;
+                    while (true) {
+                        nextJSDocToken();
+                        switch (token()) {


Can we return false; in the default case? It looks like if we keep encountering some other kind of token, we'll go all the way to the end of the file.

Not really; we hit the default case a lot for punctuation and identifiers that we want to skip as part of the tag's description.

Note that it's the end of the comment, not the end of the whole file. And we return false as soon as tryParseChildTag encounters any tag that is not param, type or property. So runaway parsing shouldn't be a big problem.

Also note: Comments aren't handled by this PR but once they are, default will probably look like parseJSDocCommentWorker, where it just pushes the token into a comment array.

sandersn · 2017-07-26T19:21:02Z

I think this is ready to go unless you have more comments.

sandersn · 2017-07-26T21:38:42Z

Addressed the comment I missed previously.

sandersn added 3 commits July 21, 2017 14:04

Update JSDocParsing unit test baselines

8d2d226

Test: jsdoc @param type literals

e942bbb

msftclas added the cla-not-required label Jul 21, 2017

sandersn requested review from a user and weswigham July 21, 2017 21:56

sandersn mentioned this pull request Jul 21, 2017

Intellisense for object properties defined in multi-line JSDoc comments #11597

Closed

@param parsing:const enum to improve readability

5996139

weswigham approved these changes Jul 24, 2017

View reviewed changes

ghost reviewed Jul 24, 2017

View reviewed changes

ghost reviewed Jul 25, 2017

View reviewed changes

sandersn added 2 commits July 25, 2017 14:14

Address PR comments from Andy

c55a043

I'll take a look at Wesley's next and see if those require any changes.

Update baselines

58ad164

sandersn commented Jul 25, 2017

View reviewed changes

sandersn added 3 commits July 26, 2017 10:57

Address more PR comments

fde4c18

Update baselines

9e59dac

Merge branch 'master' into jsdoc-param-type-literals

9fd90e7

ghost reviewed Jul 26, 2017

View reviewed changes

ghost approved these changes Jul 26, 2017

View reviewed changes

sandersn merged commit fdb4465 into master Jul 26, 2017

sandersn deleted the jsdoc-param-type-literals branch July 26, 2017 22:17

sandersn mentioned this pull request Sep 7, 2017

TypeError: Cannot read property 'length' of undefined at Object.forEachChild #18301

Closed

Bibliofile mentioned this pull request Dec 13, 2017

Intellisense when specifying object properties microsoft/vscode#40181

Closed

microsoft locked and limited conversation to collaborators Jun 14, 2018

		@@ -1553,6 +1553,10 @@ namespace ts {

		/** Does the opposite of `getJSDocParameterTags`: given a JSDoc parameter, finds the parameter corresponding to it. */
		export function getParameterFromJSDoc(node: JSDocParameterTag): ParameterDeclaration \| undefined {


		function tryParseChildTag(parentTag: JSDocTypeLiteral): boolean {
		function parseChildParameterOrPropertyTag(target: PropertyLikeParse.Property): JSDocTypeTag \| JSDocPropertyTag \| false;

Parse jsdoc @param type literals #17352

Parse jsdoc @param type literals #17352

Conversation

sandersn commented Jul 21, 2017 • edited Loading

weswigham left a comment

Choose a reason for hiding this comment

ghost Jul 24, 2017 • edited by ghost Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost Jul 25, 2017 • edited by ghost Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost Jul 25, 2017 • edited by ghost Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost Jul 25, 2017 • edited by ghost Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost Jul 25, 2017 • edited by ghost Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sandersn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sandersn commented Jul 25, 2017

Choose a reason for hiding this comment

Parse jsdoc `@param` type literals #17352

Parse jsdoc `@param` type literals #17352

sandersn commented Jul 21, 2017 •

edited

Loading

ghost Jul 24, 2017 •

edited by ghost

Loading

ghost Jul 25, 2017 •

edited by ghost

Loading

ghost Jul 25, 2017 •

edited by ghost

Loading

ghost Jul 25, 2017 •

edited by ghost

Loading

ghost Jul 25, 2017 •

edited by ghost

Loading