* Fix `clippy::doc_lazy_continuation` lints
* Fix `dead_code` warnings in tests.
Protect code used in some tests based on features with feature
checks.
* Fix `clippy::needless_borrows_for_generic_args` lints
* Remove a useless conversion
* Remove a cfg_attr check for `track_caller`
This shouldn't be needed here as the test is already ignored.
Fixes: https://github.com/zkat/miette/issues/369
Diagnostic impls are no longer reset to default when converting a
`Report` into a `Box<dyn Diagnostic>`. Also prevented `Report` vtables
and handlers from being kept around on the heap after conversion.
This can be used to avoid awkward `start..(end + 1)` constructions,
which will trigger the `clippy::range_plus_one` lint.
I added a single impl for `InclusiveRange` rather than a blanket
`impl<T: RangeBounds> From<T> for SourceSpan` for two reasons. The first
is that the blanket impl would be a breaking change (because dependent
crates may currently define a type `T: RangeBounds` and also have `impl
From<T> for SourceSpan`). The second is that this would allow one-sided
ranges (`..x`, `x..`). In order to support bounded-below ranges, we
would need to change `SourceSpan` so that `length` may depend on the the
specific `SourceCode` instance. That seems like an unlikely use case.
This improves `get_lines()` logic by using a string-buffer with a capacity hint.
That avoids growing the buffer from zero each time, saving a bunch of reallocations.
* fix(docs): `alt` attribut for `single-line-example.png`
The white line breaks in the `alt` attribute prevented the `single-line-example.png` image from being displayed.
* Revert "fix(docs): `alt` attribut for `single-line-example.png`"
This reverts commit 2e97d568aa.
* fix: image link in `lib.rs` instead of `readme.md`
* feat(docs): cargo make readme
Fixes: https://github.com/zkat/miette/issues/219
When a snippet couldn't be read (typically because the span didn't fit
within the source code), it and the rest of the diagnostic were silently
dropped, which was confusing to the developer.
Now, in place of the snippet, print an error message with the name of
the failed label and the error it triggered, then proceed with the rest
of the diagnostic (footer, related, ...)
* feat(collection): add label(collection) documentation to lib.rs
* feat(collection): remove repeated formatting of label text
Because of a typo, the label text was being formatted multiple times per
label in a collection. With the fix, the text is formatted only once per
collection
* feat(collection): chain iterators rather than extend vector
Since we are going to iterate anyway, instead of growing the label vector,
chain the iterators. This should be more efficient.
In some cases, this also remove a compilation warning about the label
vector being unnecessarily mutable.
* feat(collection): remove unnecessary `OptionalWrapper`
- In a label collection, there is no need for a `None` label. One should
just not add that label
- Code wise it is also incorrect. The wrapper will be for a vector of
spans, not for individual spans. It happens to work anyway, but this was
not the intended use.
Fixes: https://github.com/zkat/miette/issues/315
Allow errors to have a number of labels determined at runtime.
An example of this is when the rust compiler labels all the arms of
a `match` expression when one of them has an incompatible type
To allow customization of the text for each label in a collection, add
support for using LabeledSpan in collections instead of just regular
spans
The default `GraphicalReportHandler` disables the printing of cause
chains for any inner errors (errors `related()` to a source diagnostic)
when it disables nested footer printing. This results in lost cause
chain information when printing with the default report handler.
Fixes: https://github.com/zkat/miette/issues/317
It turned out there were two really. One related to how many characters
were added for the arrowheads in the gutter, and one where the gutter
was extended to a number of characters, including ansi escape codes.
However, because ansi escape codes are rather big, there would never be
any extension since the system thought the string was already long
enough, even though you don't actually see the width of those codes.
Previous output looked like this:
---- single_line_with_wide_char_unaligned_span_empty stdout ----
Error: oops::my::bad
× oops!
╭─[bad_file.rs:2:4]
1 │ source
2 │ 👼🏼text
· ─▲
· ╰── this bit here
3 │ here
╰────
help: try doing it better next time?
Note that the .max(start + 1) term is still necessary in the nonempty
branch, since it's possible to have a nonempty span covering zero-width
text.
* remove uncessary if statement
start > end in all cases.
Fixes: https://github.com/zkat/miette/issues/223
This fixes a panic when an error starts inside a Unicode code point. The
range is extended to start (or end) at the beginning (or end) of the
character inside which the byte offset is located.