8000 Track end line numbers and column information by viluon · Pull Request #2499 · google/ksp · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Track end line numbers and column information #2499

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Track end line numbers and column information #2499

wants to merge 2 commits into from

Conversation

viluon
Copy link
@viluon viluon commented Jun 19, 2025 •
edited
Loading

This change aims to improve source location tracking for purposes of error reporting. I deliberately maintained backwards compatibility, however the (original) choice of textOffset for determining the line number is questionable, as it typically points to the node's identifier rather than to the actual start of the node in the source code.

For example, in the test for f1, the reported FileLocation points to the start of the identifier f1 rather than to the keyword void.

@Location
void f1(@Location int p2) {

}

I would argue a more correct implementation would use startOffset rather than textOffset, perhaps exposing textOffset via another property of FileLocation. I'm happy to make changes here but went with the backwards-compatible default.

One more thing that occurred to me is that these line & column coordinates could be tracked in smaller classes still and exposed as two (or more) pairs in FileLocation, e.g. something like

data class FileLocation(
    val filePath: String,
    val start: SourceCoordinates, // based on startOffset
    val end: SourceCoordinates,
    val text: SourceCoordinates, // an extension based on textOffset
) : Location()

might be a better model. Such a backwards-incompatible API change might be rejected outright or take too long to incorporate and I'd personally prefer some column information rather than none. I'm happy to propose the necessary changes if maintainers are willing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@viluon
307E
0