[BUG]: Emoji in workflow will crash Zizmor

[peterflat]

Pre-submission checks

• I am not filing a feature request. These should be filed via the feature request form instead.
• I have looked through the open issues for a duplicate report.

Expected behavior

I expected Zizmor to handle my silly workflow that has unicode chars in it.

Actual behavior

Zizmor provided a very courteous notification and crash report.

Reproduction steps

Put an emoji in a workflow and run zizmor in that directory or on that workflow directly. For example 🚀 ...

Logs

"name" = "zizmor"
"operating_system" = "Mac OS 15.1.1 [64-bit]"
"crate_version" = "0.8.0"
"explanation" = """
Panic occurred in file '/Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/annotate-snippets-0.11.4/src/renderer/display_list.rs' at line 369
"""
"cause" = '''byte index 167 is not a char boundary; it is inside '🚀' (bytes 164..168) of ...
"method" = "Panic"
"backtrace" = """
   0:        0x104060238 - backtrace::capture::Backtrace::new::hc766bbdbd5f62069
   1:        0x1040ccc60 - human_panic::report::Report::new::h69c8a5003441220f
   2:        0x1043912c4 - human_panic::setup_panic::{{closure}}::h6600a068b8f2cfed
   3:        0x104296f14 - std::panicking::rust_panic_with_hook::h7d795911432661cb
   4:        0x104296bf4 - std::panicking::begin_panic_handler::{{closure}}::h36f15310ecbde379
   5:        0x104296b64 - std::sys::backtrace::__rust_end_short_backtrace::heed121414170e0c7
   6:        0x104296b58 - _rust_begin_unwind
   7:        0x1044348d4 - core::panicking::panic_fmt::h17b1b80ec02ffd19
   8:        0x1040b802c - core::str::slice_error_fail_rt::hc9374d178fc3b440
   9:        0x104434d6c - core::str::slice_error_fail::hcaf6c10690349a36
  10:        0x10404841c - <annotate_snippets::renderer::display_list::DisplayList as core::fmt::Display>::fmt::h91834c4f0842b0e1
  11:        0x1040b1e9c - core::fmt::write::h381c0b0ce6ab972a
  12:        0x1042df12c - std::io::Write::write_fmt::hf40231a743f440e2
  13:        0x1043c1450 - <anstream::auto::AutoStream<S> as std::io::Write>::write_fmt::h3b7e71d81485b52d
  14:        0x1043bcde8 - zizmor::render::render_findings::hfd60b56526d645d9
  15:        0x1043b2844 - zizmor::run::hbc7f2116607e26c3
  16:        0x1043a7d40 - zizmor::main::he0126afb2a6287fb
  17:        0x104393104 - std::sys::backtrace::__rust_begin_short_backtrace::h4f154809c2176657
  18:        0x1043a79ac - _main
"""

Additional context

No response

[woodruffw]

Thanks for the report @peterflat!

This is a nice confirmation that our panic handler works as expected, although it's not ideal that you hit this crash 😅

Is there any chance you could share the crashing workflow? I have some testcases that use emojis and haven't seen this, so I'm wondering if it's something unusual.

[woodruffw]

For reference, I put 🚀 in a few workflows just now, and couldn't reproduce this. I suspect it needs to happen in a finding somewhere based on the crash in render_findings, although I'm not sure where we'd end up slicing within an emoji there.

Edit: based on the full context, this appears to happen due to a slice within annotate-snippets, somewhere within this Display impl:

https://github.com/rust-lang/annotate-snippets-rs/blob/c0f4f81987565ffd4054b1269c07e4ef68914386/src/renderer/display_list.rs#L73-L114

[woodruffw]

Looks like this may have been a regression in annotate-snippets: rust-lang/annotate-snippets-rs#161

[woodruffw]

#264 is a candidate fix for this. @peterflat if you could give that branch a try I'd greatly appreciate it!