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

Graphical handler panics when span endpoints are not aligned to char boundaries #223

Closed
Benjamin-L opened this issue Nov 3, 2022 · 1 comment · Fixed by #312
Closed
Labels
bug Something isn't working

Comments

@Benjamin-L
Copy link
Contributor

This is another regression introduced by #202.

Steps to reproduce

Source: source\n 👼🏼text\n here
Span: (10, 5)

Result:

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]
fn single_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?"))]
  struct MyBad {
      #[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 │ source
2 │   👼🏼text
 ·   ────┬───
 ·       ╰── this bit here
3 │     here
 ╰────
help: try doing it better next time?
"#
  .trim_start()
  .to_string();
  assert_eq!(expected, out);
  Ok(())
}

#[test]
fn single_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?"))]
  struct MyBad {
      #[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 │ source
2 │   text 👼🏼
 ·   ───┬───
 ·      ╰── this bit here
3 │     here
 ╰────
help: try doing it better next time?
"#
  .trim_start()
  .to_string();
  assert_eq!(expected, out);
  Ok(())
}
@Benjamin-L
Copy link
Contributor Author

Originally reported in #221 (comment).

@zkat zkat added the bug Something isn't working label Nov 24, 2022
MattX added a commit to MattX/miette that referenced this issue Nov 2, 2023
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.

Fixes zkat#223.
@zkat zkat closed this as completed in #312 Nov 2, 2023
zkat pushed a commit that referenced this issue Nov 2, 2023
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants