Extra `*` characters inserted around decorator in fenced code block in JSDoc
Does this issue occur when all extensions are disabled?: Yes
- VS Code Version: 1.67.0-insider (commit: f050b17dacedba13962244b13c70084a473d08f7)
- OS Version: Windows 11
Steps to Reproduce:
- Open a TypeScript file in VSCode
- Create a variable or type and add a JSDoc comment
- Inside the JSDoc comment, add a fenced code block for the TypeScript language (i.e.,
```ts) - Inside the fenced code block add
@decorator class C {} - Bring up the quick info/hover for the documented element.
- Observe that in the documentation, the decorator is rendered as
*@decorator*.

NOTE: This occurs regardless as to whether the @example tag is used, as the problem always occurs when using a fenced code block.
Similar to #39371
Minimal code sample:
/**
* @example
* ```ts
* @blablabla
* foo()
* ```
*/
function foo() { }
And TS response:
[Trace - 17:39:58.92] <semantic> Response received: quickinfo (309). Request took 2 ms. Success: true
Result: {
"kind": "function",
"kindModifiers": "",
"start": {
"line": 8,
"offset": 10
},
"end": {
"line": 8,
"offset": 13
},
"displayString": "function foo(): void",
"documentation": [],
"tags": [
{
"name": "example",
"text": [
{
"text": "```ts",
"kind": "text"
}
]
},
{
"name": "blablabla",
"text": [
{
"text": "foo()\n```",
"kind": "text"
}
]
}
]
}
Decorators are non-experimental now in TypeScript 5. Can this please be fixed? 🙏
A workaround for this is to escape the ampersand, like this: \@foo. This will leave the code formatted as is, but the drawback is that backslashes will appear in the code example. I've been doing it like so, for now telling people to ignore backslashes every time:
/**
* Example (ignore backslashes):
*
* ```js
* \@behavior
* class MyBehavior extends Behavior {
* \@numberAttribute foo = 123
* }
* ```
*/
Output:
Same issue with @ts-* magic comments within an example:
/**
* @example
* ```ts
* // @ts-ignore
* fn(1)
* ```
*/
declare function fn(arg: string): unknown
I don't have any knowledge of the JSDoc parser, but surely only ``` (or equivalent ending fence chars ~~~ etc) should end the code block? Not sure why @ is breaking out of that context.
Workaround: replace @ with @ (U+FF20 "fullwidth commercial at").
One potential solution could be introducing proper support for code fences in parseTagComments. Currently each occurrence of "@" will break the comment text and start a new tag.
What file does the JSDoc parsing logic live in? This bug has been driving me nuts for at least a year and a half now. I'll take a stab at it. Shouldn't be too difficult to ensure we aren't inside a fenced codeblock before deciding an @-prefixed string is a JSDoc tag...
Tracking at #47679 now
This issue has been marked as "Duplicate" and has seen no recent activity. It has been automatically closed for house-keeping purposes.