Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(on_result_diagnostic): treat end_lnum < 1 as unitialized #396

Conversation

ruslanSorokin
Copy link
Contributor

The end of the diagnostic range was previously calculated as item.end_lnum and item.end_lnum - 1. Given item = { lnum: 95, end_lnum: 0, ... }, this calculation would span everything from the beginning up to line 95. I believe that an end_lnum value of zero should be treated as uninitialized (because lines are 1-indexed). Therefore, I think the item should be considered a single-line item.

@github-actions github-actions bot requested a review from stevearc January 10, 2025 09:13
@ruslanSorokin ruslanSorokin force-pushed the fix/no-ref/check-end_lnum-bounds-as-1-indexed branch from f42e163 to 476d400 Compare January 10, 2025 09:32
The end of the diagnostic range was previously calculated as `item.end_lnum and item.end_lnum - 1`. Given `item = { lnum: 95, end_lnum: 0, ... }`, this calculation would span everything from the beginning up to line 95. I believe that an `end_lnum` value of zero should be treated as uninitialized (because lines are 1-indexed). Therefore, I think the item should be considered a single-line item.
@ruslanSorokin ruslanSorokin force-pushed the fix/no-ref/check-end_lnum-bounds-as-1-indexed branch from 476d400 to b6d5352 Compare January 10, 2025 09:44
@@ -68,7 +68,7 @@ local comp = {
message = item.text,
severity = type_to_severity[item.type] or vim.diagnostic.severity.ERROR,
lnum = (item.lnum or 1) - 1,
end_lnum = item.end_lnum and (item.end_lnum - 1),
end_lnum = (item.end_lnum and item.end_lnum > 0) and (item.end_lnum - 1) or item.lnum,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is starting to get beyond what is readable for a single line. Can you refactor into multiple lines above?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the feedback! I've gotten rid of the ternary operator for better readability as requested and also made it explicit that an uninitialized end_lnum gets value of lnum + 1. Let me know if further adjustments are needed!

@github-actions github-actions bot requested a review from stevearc January 13, 2025 04:01
@stevearc
Copy link
Owner

LGTM, thanks!

@stevearc stevearc merged commit 35b729b into stevearc:master Jan 16, 2025
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants