zkat / miette Goto Github PK
View Code? Open in Web Editor NEWFancy extension for std::error::Error with pretty, detailed diagnostic printing.
Home Page: https://docs.rs/miette
License: Apache License 2.0
Fancy extension for std::error::Error with pretty, detailed diagnostic printing.
Home Page: https://docs.rs/miette
License: Apache License 2.0
The wrapper Diagnostic
types that Report
uses should be marked as transparent
diagnostics, so stuff like snippets and codes show up when you .context()
on something. Oops!
Miette currently only supports a single "help" message, at the end of a whole diagnostic. It might be handy to do something like what rustc does, where multiple info/help
messages can be attached to snippets themselves? This might potentially be resolved instead by whatever #47 ends up looking like, with the addition of multiple "footer" labels (help/info/suggestion/etc).
The current derive macro supports code
, help
, and derive
, but doesn't really handle the snippet
part of miette. Extend the macro so that you can write stuff like this:
#[derive(Debug, Error, Diagnostic)]
#[diagnostic(code(math::bad_arithmetic))]
#[error("Tried to add a {bad_type} to a {good_type}")]
pub struct MyErr {
good_type: Type,
bad_type: Type,
bad_var: Var,
src: PathBuf,
// The overall span of code that will be rendered.
#[context(src, "This region is where things went wrong")]
ctx: SourceSpan,
// A highlight (basically something to underline)
#[highlight(ctx, "This is a {bad_type}")]
bad_var_span: SourceSpan,
// Can have multiple highlights.
#[highlight(ctx, "This is a {good_type}")]
good_var_span: SourceSpan,
}
This is something that color-eyre
is able to do nicely. It would be really nice to have for miette!
I'm implementing Diagnostic
manually for an error type so that it can provide different labels depending on the nature of the error. While testing, I noticed this report, which seems to render the span of the here
label incorrectly:
Error: glob::rule
x invalid glob expression: singular tree wildcard `**` in alternative
,----
1 | {foo,**,bar,baz}
: ^^^^^^^^|^^^^^^^
: |`-- here
: `-- in this alternative
`----
I printed the LabeledSpan
s provided by Diagnostic::labels
and they look correct to me:
[LabeledSpan { label: Some("in this alternative"), span: SourceSpan { offset: SourceOffset(0), length: SourceOffset(16) } }, LabeledSpan { label: Some("here"), span: SourceSpan { offset: SourceOffset(5), length: SourceOffset(2) } }]
Note that the span for the here
label has an offset of 5 and length of 2, which should isolate **
in the source text for this error. I've tried relocating the token that ultimately emits this error and the span always appears correct but renders in the same way (spanning the entire alternative token). It almost looks as if the span is being replaced by the span of the in this alternative
label.
I'm using version 3.0.0
of miette
and other cases using as many as three separate labels render as expected. Any ideas? Thanks!
The default reporters are fantastic, and there's even hooks to customize them with, but you're kinda stuck with the overall look beyond what the GraphicalTheme provides.
It's not ideal for everyone using miette to have "the miette look". It should be possible (and easy!) to piece together your own handler while still taking advantage of the fairly complex snippet and such reporting code.
This might also involve merging the graphical and narrated handlers into two modes of one big handler (maybe even include #29 in that). Also all the logic for switching between them and figuring out some terminal specific things.
This is the roadmap of major or breaking changes that are meant to land with [email protected]
. Is there anything you'd like to see here? Feel free to start a discussion about it (under "ideas").
Probably breaking changes:
Stuff that can probably land sooner, but should be in by 3.0:
Stuff we need to remember to do right before tagging the release:
This sounds a bit strange, but I have a cli handling CTRL+C, including from stdin prompts, and it would be nice if the error case for that could be more minimal than the rest.
So it turns out that derive
macros can't expand anything in-place: they can only generate new code in a completely different area.
We need a #[document_codes]
attribute macro that you can slap at the toplevel of anything using the Diagnostic
derive, which goes through and adds #[doc(alias = "my::code::here")]
to the error struct or enum, in the appropriate places.
This might be tricky because you're injecting stuff in the middle of a tokenstream, but maybe it's easier than it sounds?
Right now, miette supports multiple snippets. It also supports a single cause chain (though all .source()
s have to be StdError
instead of Diagnostic
.
It would be nice for miette, maybe at the Report
level, to support multiple diagnostics in some way that makes sense. This issue needs some thinking and investigation into actual use-cases before implementation/proposal.
One really cool relatively recent addition to rustc is the ability to add suggestions (in green) that propose specific changes to a snippet and highlight the changed text. It would be nice for this to have first-class support in miette. Maybe it can be implemented by just adding a "type" to DiagnosticSnippet to change its display mode?
Would be nice if we could render things nicely with colors and everything, out of the box. I really like what https://github.com/zesterer/ariadne is doing on that front!
This goes back to #23, when the "header" concept was introduced. The header is not rendered at all when the source returns None for .name()
. (Back in v0.12 you needed SourceSpan::new_labeled.)
Workaround atm is to give every source a name. But given Source is implemented for unnamed String
/Arc<String>
miette should be able to render the header without a name.
Using String
/ Arc<String>
Error: โโโโ[code::here]โโโโโโโโโโโโโโโโโโโโ
ร std::error::Error display message
1 โ one two thre
ยท โโฌโ
ยท โฐโโ highlight message
Using NamedSource
Error: โโโโ[code::here]โโโโโโโโโโโโโโโโโโโโ
ร std::error::Error display message
โญโโโ[example.txt:1:1] snippet message:
1 โ one two thre
ยท โโฌโ
ยท โฐโโ highlight message
Now that I figured out the issue, it's like a few lines to edit across a few printers, so lemme give it a go.
While I'm thinking about this, I think we could implement Source on &'static str
because these can be cloned just as freely as the others and are obviously 'static
. Not super useful except for testing.
I'm using miette
in a parser that deals with tab \t
indents and so far noticed the following:
miette
renders one \t
as the number of spaces configured in the terminal (OK)miette
counts one \t
's width as equal to one space and displays the arrow/label according to this width (Breaks because of the above, but should be possible to deal with by the developer)So I decided to calculate number of tabs in the line, multiply it by tab width, and add that to the offset minus the number of tabs. Example:
\t\t
with tab width 4 = 8SourceSpan
(16, 0)In my repro this places the arrow in the correct position. But weird stuff happens if I have a really big offset (exactly 37 and more chars). It either just renders the line without rendering arrow/label or simply panics with this error:
thread 'main' panicked at 'failed printing to stderr: formatter error', library/std/src/io/stdio.rs:935:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Here's a reproduction:
https://github.com/jlkiri/miette-tab-error-repro
Some modern terminal support escape codes that can be used to insert clickable links on terminal text. These are used, for example, in GCC's diagnostic output.
It would be great if the error codes output by miette's terminal formatter would be clickable links that directly open the documentation page for the error.
Some information about the terminal escapes for links is here: https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
Right now, help
is pretty limited as far as formatting goes. It should be expanded to allow everything thiserror
supports, including shorthand format strings and enum variant access.
I'm getting the following on cargo t
:
failures:
---- src\compile_test.rs - compile_test::ForwardWithoutCode (line 113) stdout ----
Test compiled successfully, but it's marked `compile_fail`.
---- src\compile_test.rs - compile_test::ForwardWithoutCode (line 98) stdout ----
Test compiled successfully, but it's marked `compile_fail`.
failures:
src\compile_test.rs - compile_test::ForwardWithoutCode (line 113)
src\compile_test.rs - compile_test::ForwardWithoutCode (line 98)
@cormacrelf does this make any sense to you? Did your more recent changes make this issue moot?
I try to use miette with a parser, if the node parsed is of type error then I use miette to render the error. I have an issue because in miette it seems you're skipping '\n' and whitespaces into the source code. Then when I try to specify my SourceSpan thanks to the byte position it doesn't work at all because it the byte position with whitespaces and in your code you use the source_code string without any whitespaces.
How can I do this correctly ?
example of my code:
let err = ParsingError {
bad_bit: (node.start_byte(), node.end_byte()).into(), // ISSUE HERE
src: src.to_string(),
};
Allowing dynamic list of spans to provide highlights you can be good for using miette to wrap tools like TypeScript (tsc).
Looking at the source code, maybe Vec<SourceSpan>
might not cut it, but introducing a new LabelledSourceSpan
and allowing everything that is Into<Vec<LabelledSourceSpan>>
could also make sense.
What do you think?
Add support for syntax highlighting through syntect.
I figure this can be done by having the graphical handler take an optional SyntaxSet, and have an optional identifier token method as part of SpanContents
, so the renderer can color code accordingly.
The biggest challenge here is designing things such that things are appropriately feature flagged and don't grow binaries too much?
This is going to be hard, but it's going to make out-of-the-box display for, say, a bunch of single-line json, a lot easier.
We need to test against a list of known terminals that support clickable links, and only linkify on those terminals. Otherwise, URLs should be displayed fully, possibly as part of a footer.
Might be nice to have a reporter that's able to output errors as JSON.
Ref: #28 (comment).
In @zkat's tweet https://twitter.com/zkat__/status/1428962008699793412/photo/1, the final message is
This is a bug. It might be in ruget, or it might be in the source
you're using, but it's definitely a bug and should be reported.
The question arises, to whom or what should the bug be reported?
Providing a link to both ruget and miette's Issues pages would be a great start, and if it's not in miette or ruget then whoever is maintaining those projects can guide the submitter to a more appropriate project to file a bug with.
thread 'single_line_highlight' panicked at 'attempt to subtract with overflow', .../miette/src/printer/graphical_printer.rs:388:29
I can reproduce this with the existing test suite by changing the 4 to 0 here:
Line 44 in 7e76e2d
Miette should be able to automatically print a static or customizable error message as a footer to all generic errors for you.
For example:
Need help? Check out https://voltpkg.com/troubleshoot/internet::connection::404 <- notice the fact that i can add my custom error code here
How accessible are these errors? What changes could be made to make them easier to consume for visually impaired folks? We should have a reasonable story for this before 1.0 goes out. Right now, I don't imagine it's very useful to get these error messages.
Particularly because I expect people will be using the derive most of the time, it would be good if the reporter/DiagnosticSnippet
can understand the protocol and folks can put their own span types into the derive?
This will make it possible to delay providing source_code
until the app is ready to provide it, which is a common pattern in compilers.
I'm not sure the current reporter will render highlights correctly if you have, say, doublewidth character, tabs, etc?
No rush, I think, because the intention is very much that anyone using miette will also probably be using the reporter, but I'm hoping people write their own bespoke reporters against the "protocol".
...maybe that means we need miette-protocol
, and miette
is the Big Chonker library? That would let us do this refactor without being semver-breaking. ๐ค
Hey,
First up, this library is dope. Love your work. ๐
I'm having one small issue though - if I have a SourceSpan
that points somewhere in the first line of some source code, that first line seems to get chopped.
Here's a test to reproduce:
#[cfg(test)]
mod miette_test {
use miette::{
Diagnostic, GraphicalReportHandler, GraphicalTheme, SourceSpan, ThemeCharacters,
ThemeStyles,
};
use thiserror::Error;
#[derive(Error, Debug, Diagnostic)]
#[error("some error")]
#[diagnostic(help("where did the word 'imagine' go!?"))]
struct SomeError {
#[source_code]
some_code: String,
#[label("'imagine' should come before this")]
some_span: SourceSpan,
}
#[test]
fn whytho() {
let mut rendered = String::new();
let diagnostic = SomeError {
some_code: "imagine this is some code\n\nyou're seeing all of this line".to_owned(),
some_span: (8, 0).into(),
};
GraphicalReportHandler::new()
.with_theme(GraphicalTheme {
characters: ThemeCharacters::ascii(),
styles: ThemeStyles::none(),
})
.with_context_lines(3)
.render_report(&mut rendered, &diagnostic)
.unwrap();
assert_eq!(
&rendered,
r#"
x some error
,-[1:1]
1 | this is some code
: ^
: `-- 'imagine' should come before this
2 |
3 | you're seeing all of this line
`----
help: where did the word 'imagine' go!?
"#
);
}
}
https://github.com/rust-cli/human-panic seems neat. Is this something miette should do? I'm not sure
Only enable this when the user asks for it, tho
everything, including the derive macro, should be well-documented, with reasonable guide-level documentation showing folks how to use miette!
You might want to support this: https://bixense.com/clicolors/
It's a better (and older) alternative to NO_COLOR that a number of tools support.
Looks like a nice crate btw, I will try it in my next project!
One of the nice things that miette should handle out of the box is having highlights that point to multi-line code blocks.
The protocol as it is right now should be able to handle it just fine, but this seems like just a generally pretty hard thing to write a reporter for, so I'm struggling.
Let me know if you care a lot about this and I'll gladly leave it in your hands, though!
Everyone has their own spans. We shouldn't force ours on them. They should be able to return their own span types as part of their error types, as long as that type can be converted into a SourceSpan
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.