getLeadingCommentRanges misses comment in call expression

Bug Report

getLeadingCommentRanges misses comments that are in front of arguments passed to a call expression.

Comments being missed is a known issue when comments are within a node between tokens not stored in the tree: https://github.com/Microsoft/TypeScript/wiki/FAQ#why-some-comments-are-not-preserved-in-emitted-javascript-even-when---removecomments-is-not-specified

However that is not the case here and in fact tsc will preserve that particular comment.

Note: here I refer to getLeadingCommentRanges but in reality the bug is present inside of iterateCommentRanges (what getLeadingCommentRanges uses under the hood)

🔎 Search Terms

• leading, trailing comment undefined
• getLeadingCommentRanges, getTrailingCommentRanges
• Call expression, function call, method call

🕗 Version & Regression Information

• This is the behavior in every version I tried (4.3.5 (the oldest version on ts-ast-viewer.com), 5.1.6, @next (5.2.0-dev.20230706))

⏯ Playground Link

https://ts-ast-viewer.com/#code/MYewdgziA2CmB00QHMAUB6AVAAgBa2iW03WwCIB3EAJ2gBMyBKIA

💻 Code

console.log(/* hello */ "world")

Calling getLeadingCommentRanges on the string literal returns undefined.

🙁 Actual behavior

ts.getLeadingCommentRanges('console.log(/* hello */ "world")', 12)

returns undefined

🙂 Expected behavior

ts.getLeadingCommentRanges('console.log(/* hello */ "world")', 12)

returns [ { kind: 3, start: 12, end: 23, hasTrailingNewLine: false } ]

Reproduce the issue with ts.getLeadingCommentRanges on console.log(/* hello */ "world") at offset 12, then trace the iterateCommentRanges path used by getLeadingCommentRanges. The work is done when the call returns the expected comment range for the string literal without regressing related leading or trailing comment handling.