You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
thread 'single_line_with_wide_char_unaligned_span_start' panicked at 'byte index 3 is not a char boundary; it is inside '👼' (bytes 2..6) of ` 👼🏼text`', library/core/src/str/mod.rs:127:5
Expected Behavior
When the span boundaries are inside a char, the rendered highlight should extend to include that char instead of panicking.
This is almost the same as the current behavior of the narratable report handler. The current narratable report handler behaves differently when the start of the span is not char-aligned. In this case, the reported span does not include the char that the span start is inside. I think it makes more sense for the start of the span to be extended backwards, and and then end to be extended forwards. This way, whenever a span endpoint lies inside a char, that char is always included.
Unit tests for this
#[test]fnsingle_line_with_wide_char_unaligned_span_start() -> Result<(),MietteError>{#[derive(Debug,Diagnostic,Error)]#[error("oops!")]#[diagnostic(code(oops::my::bad), help("try doing it better next time?"))]structMyBad{#[source_code]src:NamedSource,#[label("this bit here")]highlight:SourceSpan,}let src = "source\n 👼🏼text\n here".to_string();let err = MyBad{src:NamedSource::new("bad_file.rs", src),highlight:(10,5).into(),};let out = fmt_report(err.into());println!("Error: {}", out);let expected = r#"oops::my::bad× oops! ╭─[bad_file.rs:1:1]1 │ source2 │ 👼🏼text · ────┬─── · ╰── this bit here3 │ here ╰────help: try doing it better next time?"#.trim_start().to_string();assert_eq!(expected, out);Ok(())}#[test]fnsingle_line_with_wide_char_unaligned_span_end() -> Result<(),MietteError>{#[derive(Debug,Diagnostic,Error)]#[error("oops!")]#[diagnostic(code(oops::my::bad), help("try doing it better next time?"))]structMyBad{#[source_code]src:NamedSource,#[label("this bit here")]highlight:SourceSpan,}let src = "source\n text 👼🏼\n here".to_string();let err = MyBad{src:NamedSource::new("bad_file.rs", src),highlight:(9,6).into(),};let out = fmt_report(err.into());println!("Error: {}", out);let expected = r#"oops::my::bad× oops! ╭─[bad_file.rs:1:1]1 │ source2 │ text 👼🏼 · ───┬─── · ╰── this bit here3 │ here ╰────help: try doing it better next time?"#.trim_start().to_string();assert_eq!(expected, out);Ok(())}
The text was updated successfully, but these errors were encountered:
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.
Fixeszkat#223.
Fixes: #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.
This is another regression introduced by #202.
Steps to reproduce
Source:
source\n 👼🏼text\n here
Span: (10, 5)
Result:
Expected Behavior
When the span boundaries are inside a char, the rendered highlight should extend to include that char instead of panicking.
This is almost the same as the current behavior of the narratable report handler. The current narratable report handler behaves differently when the start of the span is not char-aligned. In this case, the reported span does not include the char that the span start is inside. I think it makes more sense for the start of the span to be extended backwards, and and then end to be extended forwards. This way, whenever a span endpoint lies inside a char, that char is always included.
Unit tests for this
The text was updated successfully, but these errors were encountered: