Conversation
|
This change is |
PR SummaryLow Risk Overview Instead of assuming the URL starts two bytes after the parser’s label end, Regression coverage adds expected Reviewed by Cursor Bugbot for commit 7033bf5. Bugbot is set up for automated code reviews on this repo. Configure here. |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 63982e5. Configure here.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 63982e5e08
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
63982e5 to
7033bf5
Compare
TomerStarkware
left a comment
There was a problem hiding this comment.
@TomerStarkware reviewed 2 files and all commit messages, and made 1 comment.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on eytan-starkware).
Summary
Fixes incorrect destination span computation for inline Markdown links whose labels contain markup (e.g.
[**bold**](path)). The](boundary separating the label from the destination was assumed to be immediately adjacent to the label's end offset, but when the label contains emphasis or other inline markup, the parser-reported label end does not point directly at](. The fix searches forward in the raw content string from the label's end to locate the actual](before computing the destination range. Thecontentstring is now threaded throughlocation_from_link_fieldsandfind_inline_destination_rangeto enable this lookup.Type of change
Please check one:
Why is this change needed?
When a doc comment link label contained bold or italic markers such as
[**bold**](path), the computeddest_spanpointed to the wrong byte range in the source text. This caused incorrect go-to-definition or hover behavior for those links because the destination text offset was shifted by the length of the markup characters inside the label.What was the behavior or documentation before?
find_inline_destination_rangeassumed the destination started exactly 2 bytes after the label's end offset (i.e., immediately after](). For plain labels this is correct, but for labels with inline markup the Markdown parser reports the label end at the closing**or*, not at], so the computed destination range was wrong.What is the behavior or documentation after?
find_inline_destination_rangenow scans forward in the raw comment string from the label's end to find the](token, then computes the destination range relative to that position. Links like[**bold**](path)and[*em*](path2)now produce correctdest_spanvalues, as verified by the new test cases.Related issue or discussion (if any)
Additional context
A new test case covering
[**bold**](path)and[*em*](path2)in the same doc comment is added todocumentation_comment_parser_links.txtto prevent regressions.