Bat Panics on Haskell Source Code

[severen]

Both Bat 0.7.0 and 20b02e7 (latest checkout of master) panic on very basic Haskell source code. Since it doesn't panic when piping the output, or upon further inspection, when I remove any type declarations (which look like main :: IO ()), it seems that the issue may lie in the syntax highlighter.

I've also confirmed that Bat works perfectly fine with a bunch of other regular files I have lying around, just to be sure.

Here's the error/output with RUST_BACKTRACE=1 on 20b02e7:

bat env RUST_BACKTRACE=1 cargo run --release ../Program.hs
    Finished release [optimized] target(s) in 0.35s
     Running `target/release/bat ../Program.hs`
thread 'main' panicked at 'begin <= end (7 <= 5) when slicing `main :: IO ()
`', libcore/str/mod.rs:2098:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:511
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:426
   6: rust_begin_unwind
             at libstd/panicking.rs:337
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:92
   8: core::str::slice_error_fail
             at libcore/str/mod.rs:0
   9: core::str::traits::<impl core::slice::SliceIndex<str> for core::ops::range::Range<usize>>::index::{{closure}}
  10: <syntect::highlighting::highlighter::HighlightIterator<'a, 'b> as core::iter::iterator::Iterator>::next
  11: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter
  12: syntect::easy::HighlightLines::highlight
  13: <bat::printer::InteractivePrinter<'a> as bat::printer::Printer>::print_line
  14: bat::controller::Controller::run
  15: bat::main
  16: std::rt::lang_start::{{closure}}
  17: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  18: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:105
  19: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  20: main
  21: __libc_start_main
  22: _start
───────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: Program.hs
───────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ module Main where
   2   │ 

And here is the most minimal Haskell source code Bat panics on:

module Main where

main :: IO ()
main = putStrLn "Please show my file :c"

[sharkdp]

Thank you very much for the detailed bug report!

I'm not 100% sure, but it looks like this is a bug in syntect. I'm still investigating.

[erkin]

I'm having the exact same problem with OCaml code, in case that makes a difference. Here's the stack trace:

bat % env RUST_BACKTRACE=1 cargo run --release /tmp/test.ml
    Finished release [optimized] target(s) in 0.23s                                                                                                                            
     Running `target/release/bat /tmp/test.ml`
thread 'main' panicked at 'begin <= end (56 <= 42) when slicing `      match (try Some (input_line i) with End_of_file -> None) with
`', libcore/str/mod.rs:2098:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:477
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:391
   6: rust_begin_unwind
             at libstd/panicking.rs:326
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   8: core::str::slice_error_fail
             at libcore/str/mod.rs:0
   9: core::str::traits::<impl core::slice::SliceIndex<str> for core::ops::range::Range<usize>>::index::{{closure}}
  10: <syntect::highlighting::highlighter::HighlightIterator<'a, 'b> as core::iter::iterator::Iterator>::next
  11: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter
  12: syntect::easy::HighlightLines::highlight
  13: <bat::printer::InteractivePrinter<'a> as bat::printer::Printer>::print_line
  14: bat::controller::Controller::run
  15: bat::main
  16: std::rt::lang_start::{{closure}}
  17: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  18: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  19: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  20: main
  21: __libc_start_main
  22: _start

The offending line is:

      match (try Some (input_line i) with End_of_file -> None) with

Hope that helps.

[sharkdp]

Apparently there was some weird bug in the binary syntax set that I created for the 0.7.0 release. Commit 238482e should fix this.

[sharkdp]

Fixed in v0.7.1

[erkin]

The problem persists on my end.

~ % bat --version
bat 0.7.1
~ % RUST_BACKTRACE=1 bat tmp/graph.ml
thread 'main' panicked at 'begin <= end (56 <= 42) when slicing `      match (try Some (input_line i) with End_of_file -> None) with
`', libcore/str/mod.rs:2098:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:477
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:391
   6: rust_begin_unwind
             at libstd/panicking.rs:326
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   8: core::str::slice_error_fail
             at libcore/str/mod.rs:0
   9: core::str::traits::<impl core::slice::SliceIndex<str> for core::ops::range::Range<usize>>::index::{{closure}}
  10: <syntect::highlighting::highlighter::HighlightIterator<'a, 'b> as core::iter::iterator::Iterator>::next
  11: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter
  12: syntect::easy::HighlightLines::highlight
  13: <bat::printer::InteractivePrinter<'a> as bat::printer::Printer>::print_line
  14: bat::controller::Controller::run
  15: bat::main
  16: std::rt::lang_start::{{closure}}
  17: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  18: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  19: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  20: main
  21: __libc_start_main
  22: _start
^C

[sharkdp]

@erkin Thank you. Interestingly, this does seem to be caused by something else and is actually a bug in syntect: trishume/syntect#176 (comment)

Edit: Actually, I didn't completely understand why the error is fixed for Haskell files. It might be that some versions of the Haskell language definition also trigger the same error.

[sharkdp]

Fixed in v0.8.0.