Out of bounds index in `parse_snippet`

[jsgf]

I'm using rustfix as a library as part of a different tool. I'm occasionally see it fail with the panic:

thread 'main' panicked at 'index 18446744073709551615 out of range for slice of length 0', src/libcore/slice/mod.rs:2674:5

(and similar bounds errors)

This corresponds to

rustfix/src/lib.rs

Line 137 in cb85f85

&last_slice[indent..last_tail_index]

. However span is:

(gdb) p *span
$2 = rustfix::diagnostics::DiagnosticSpan {file_name: "build/rust/src/liballoc/string.rs", byte_start: 8492, byte_end: 8531, line_start: 282, line_end: 284, column_start: 1, column_end: 2, is_primary: false, text:
Vec<rustfix::diagnostics::DiagnosticSpanLine>(len: 3, cap: 3) = {
    rustfix::diagnostics::DiagnosticSpanLine {text: "", highlight_start: 1, highlight_end: 1},
    rustfix::diagnostics::DiagnosticSpanLine {text: "", highlight_start: 1, highlight_end: 1},
    rustfix::diagnostics::DiagnosticSpanLine {text: "", highlight_start: 1, highlight_end: 2}}, label: core::option::Option<alloc::string::String>::Some("similarly named struct `String` defined here"), suggested_replacement: core::option::Option<alloc::string::String>::Some(<error reading variable: Cannot create a lazy string with address 0x0, and a non-zero length.>), suggestion_applicability: core::option::Option<rustfix::diagnostics::Applicability>::Some(4), expansion: core::option::Option<alloc::boxed::Box<rustfix::diagnostics::DiagnosticSpanMacroExpansion>>::Some(0x0)}

which is causing

rustfix/src/lib.rs

Lines 128 to 131 in cb85f85

	// If we get a DiagnosticSpanLine where highlight_end > text.len(), we prevent an 'out of
	// bounds' access by making sure the index is within the array bounds.
	// `saturating_sub` is used in case of an empty file
	let last_tail_index = last.highlight_end.min(last.text.len()).saturating_sub(1);

to evaluate to -1.

[ehuss]

Hm, is this with the most recent 0.5.1 (released last week)? The intent is for that to evaluate to 0. Those are all usize values, and if I'm not mistaken 0.saturating_sub(1) should still be 0.

Maybe add a reproducible example?

[jsgf]

Hm, you're right. I have updated to 0.5.1, but this report is from when I was using 0.5.0. I cited the code from current master without carefully checking it matched the code I was looking at.