reproduce fuzz-failures

[Byron]

It's notable that this regression was introduced in v0.2.11.

❯ cargo update -p jiff
    Updating crates.io index
     Locking 2 packages to latest compatible versions
    Updating jiff v0.2.10 -> v0.2.11
    Updating jiff-static v0.2.10 -> v0.2.11
note: pass `--verbose` to see 10 unchanged dependencies behind latest

Thus, the issue didn't reproduce in v0.2.10.

Fixes #1979 and #1982 (transitively, as gix-date::parse() is invoked through gix-refspec).

Tasks

• See if this is a regression in jiff and how it can be fixed.

[Byron]

Hi @BurntSushi, the fuzzer has detected a regression in jiff introduced between v0.2.10 and v0.2.11. It reproduces here, along with a test-case which might be good to have in jiff as well.

The panic looks like this:

index out of bounds: the len is 0 but the index is 0
thread 'time::parse::fuzz::reproduce_1979' panicked at /Users/byron/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/jiff-0.2.11/src/fmt/rfc2822.rs:557:12:
index out of bounds: the len is 0 but the index is 0
stack backtrace:
   0: rust_begin_unwind
             at /rustc/794c12416b2138064af1f2746646973fafd9419d/library/std/src/panicking.rs:695:5
   1: core::panicking::panic_fmt
             at /rustc/794c12416b2138064af1f2746646973fafd9419d/library/core/src/panicking.rs:75:14
   2: core::panicking::panic_bounds_check
             at /rustc/794c12416b2138064af1f2746646973fafd9419d/library/core/src/panicking.rs:273:5
   3: jiff::fmt::rfc2822::DateTimeParser::parse_weekday
             at /Users/byron/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/jiff-0.2.11/src/fmt/rfc2822.rs:557:12
   4: jiff::fmt::rfc2822::DateTimeParser::parse_datetime
             at /Users/byron/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/jiff-0.2.11/src/fmt/rfc2822.rs:439:43
   5: jiff::fmt::rfc2822::DateTimeParser::parse_datetime_offset
             at /Users/byron/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/jiff-0.2.11/src/fmt/rfc2822.rs:404:43
   6: jiff::fmt::rfc2822::DateTimeParser::parse_zoned_internal
             at /Users/byron/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/jiff-0.2.11/src/fmt/rfc2822.rs:369:13
   7: jiff::fmt::rfc2822::DateTimeParser::parse_zoned
             at /Users/byron/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/jiff-0.2.11/src/fmt/rfc2822.rs:314:19
   8: gix_date::parse::function::rfc2822_relaxed
             at ./src/parse.rs:255:9
   9: gix_date::parse::function::parse

Maybe this is super-easy to fix for you, but if you are busy I'd also offer to try and contribute a fix.
Thanks a lot for your advice on how to proceed here.

[BurntSushi]

Nice find! Fixed here: BurntSushi/jiff#360

I'll put out a release with the fix today.

[BurntSushi]

OK, this should be fixed in jiff 0.2.12 on crates.io.

[EliahKagan]

I hope it's okay that I've pushed a commit upgrading jiff to 0.2.12.

See 0be4dd4 for details. Based on local testing as well as these results in my fork, I expect CI to pass (edit: it has passed here as well). However, since this PR is still a draft, and in case you prefer to proceed differently with it, I'll refrain from marking it non-draft or merging it.

Update: Although #1979 and #1982 have been closed automatically because the availability of jiff 0.2.12 makes fuzzing pass (Cargo.lock is not used there), it seems to me that this PR is still worth merging, since the test you added is good, and I think bumping the Cargo.toml versions of jiff to be strictly higher than the version with the bug (as done in 0be4dd4) is worthwhile too.

[Byron]

This is great, thanks so much for the quick turnaround, @BurntSushi , and of course thanks @EliahKagan for picking this up in my absence, it's much appreciated!