Conversation
Why do we need to do this all the time? can we just do the resolution on demand when an operation is needed in a jsdoc? can you please share the perf numbers. |
| //// * @param /**/[|foo|] I pity the foo | ||
| //// */ | ||
| ////function f([|foo|]: number) { | ||
| //// return foo; |
There was a problem hiding this comment.
should not this one be marked as well?
There was a problem hiding this comment.
D'oh, shouldn't have left this in. We don't support goto-implementation for parameters anyway.
|
The current baselines show no significant change. Monaco - node (v7.10.0, x64) |
TFS - node (v7.10.0, x64)
This may just be because our test cases don't use JSDoc very much, although that is probably representative of real code. |
|
if so, then you want to make sure that all the special handling of jsdoc tags in the binder is limited to js files, e.g. |
mhegazy
left a comment
There was a problem hiding this comment.
Please run the perf tests one more time. the binder has been historically sensitive to reorganizing the bind function
|
OK, looks like performance is still fine. Monaco - node (v7.10.0, x64)
TFS - node (v7.10.0, x64)
|
Fixes #2452 and #14397
Does not fix #15855, #15853, or #13371
Notes:
We now always bind jsdoc, even in typescript files. This doesn't necessarily mean that we'll get a good Symbol, but at least parent pointers will be set. I'll have to test how this branch affects performance.
forEachChildis now typed as providing aNodeArray<Node>tocbNodeArrayinstead of aNode[]. We already had casts to this effect..getChildren()on a JSDocComment node used to provide a garbage array of "tokens" as if the content was TypeScript code. Now avoid collecting tokens at all and just have it be the array of nodes fromforEachChild.