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

Accessor for the location of a diagnostic #333

Open
bjchambers opened this issue Aug 11, 2021 · 3 comments
Open

Accessor for the location of a diagnostic #333

bjchambers opened this issue Aug 11, 2021 · 3 comments

Comments

@bjchambers
Copy link

The documentation says the "location" is the first primary label. It would be helpful for programmatic consumption of the diagnostics if there was a method that exposed that. For instance, it would make it easier to show just diagnostics for a specific "location" by filtering out other locations.

@Johann150
Copy link
Collaborator

Johann150 commented Aug 12, 2021

The issue with this is that you would need the Files because the Diagnostic itself only stores a byte offset into the file. This is why the locus calculation is currently done in codespan-reporting/src/term/views.rs ll. 101-134 which is more or less while rendering.

What I think could be a sensible approach to solving this problem is to add RichDiagnostic to the public API of codespan-reporting. This would also go towards the goal of easily allowing for alternative renderers. There isnt really an issue for this, but some discussion can be found in #293 and #176. I'm not really sure if it would be a good idea to add that to the public API though.

@bjchambers
Copy link
Author

Depending on how the location is reported it shouldn't need the Files. For instance, if it just reports the minimum (FileId, usize) of the maximum primary label, it would only need the byte offset. It would only need the Files if it wanted to convert the location to a line number / column offset, right?

@Johann150
Copy link
Collaborator

I think so, but I don't see how that would be useful.

But it might make sense to implement such a function on the Diagnostic anyway because that would separate some of the code into more sensible pieces and probably also reduce some duplication between RichDiagnostic and ShortDiagnostic.

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

No branches or pull requests

2 participants