Hey, so a colleague of mine wrote https://crates.io/crates/annotate-snippets for formatting rustc-like diagnostics output. Do y'all think we should try to polish that up and use it as a crate directly? IIRC it's more or less feature compatible with the current diagnostics formatting. Would be nice to move code out of tree.
cc @Esteban Küber @oli
I'll take a look at it
Is he interested in catering to our use case? I was thinking we'd end up extracting the existing machinery out into a crate
I'm currently looking for a way to split this up into smaller parts. I would really like to work on this, but I don't have enough free time to do it all at once
ok, using a new
error-format and a separate
EmitterWriter I can now successfully print nothing instead of the human output
I'm not sure if it makes sense to open a PR for just this, so I'll continue and try to get at least some output using annotate-rs
heh, we should do $something at least. Like even just dump the main diagnostic message at file:1:1
at that point I'd be fine with merging so further development can continue without having to do all the boilerplate or bitrotting cleanup
Quick update: #61191 is a first refactoring extraction from the things I'm doing. I'm currently figuring out how to get the diagnostic code lines for each emitted diagnostic. Once that's done I'll open up a PR with the initial work.
The nice thing about using annotate-rs is that it forces us to separate the diagnostics data collection from the rendering. The current code is ..a good refactoring challenge :sweat_smile:
I don't know if it will have performance implications, though
Initial PR is up: https://github.com/rust-lang/rust/pull/61407
Now that the initial PR is merged, I want to do some small cleanups
after that I think we can turn https://github.com/rust-lang/rust/issues/59346 into a tracking issue and create new issues for the various FIXMEs. what do you think?
LLline numbers support in
I hope to have the separate issues for actionable tasks created today
I'm don't think that FIXMEs that require further investigation should get their own issues already
For example https://github.com/rust-lang/rust/blob/57a3300c2538fd1044ce45d9ef3b82182acb57ae/src/librustc_errors/annotate_snippet_emitter_writer.rs#L118 is not really worth it's own issue but should be investigated at some point
It's been two months and #61811 is done now; I wish I had more time to work on both Clippy and rustc diagnostics :sweat_smile:
I want to get back to the other two issues by end of August, unless someone else wants to have a go at them