Panic when parsing let declaration with no declarations

[jasikpark]

!!sqve+l//

l
let
///
oOo�str!er

as input for the module_roundtrip_naive fuzzer produces this error:

Running: fuzz/artifacts/module_roundtrip_naive/crash-cbb815ba074710aad65fc66c094f2e1600e0c80e
thread 'AST parsing' panicked at /Users/calebjasik-personal/Git/ezno/parser/src/declarations/variable.rs:274:63:
called `Option::unwrap()` on a `None` value

https://github.com/kaleidawave/ezno/blob/34eecf1198229424560bf390fd87b0ec82d407db/parser/src/declarations/variable.rs#L273-L276

[jasikpark]

Seems like there needs to be an error thrown when there's a let but no associated declaration?

[kaleidawave]

Hmm yes. Could start with let mut declarations = vec![VariableDeclarationItem::from_reader(...)] but yes emitting a ParseError if declarations.is_empty would be better because it could be allowed under partial_syntax so that this works

Will investigate and fix! (also same issue for const below and will check for var)

[jasikpark]

I'm thinking I may do work to integrate these mature fuzzers with OSS-Fuzz, where they can be run for longer and catch bugs like these, since it seems like they aren't catching anything on 5m Github Action runs anymore, right?

(https://google.github.io/oss-fuzz/getting-started/continuous-integration/)

[kaleidawave]

There are things being caught! I am unsure how this example hadn't been flagged by CI yet? Maybe just a rare state.

ATM things in the type checker have a lot higher priority so I am quite happy with the current level of parsing fuzzing. If you want to and is simple to change/upgrade sure! I do want to keep it under 2 mins though, it is a bit annoying to wait any longer for results.

[kaleidawave]

Fixed in https://github.com/kaleidawave/ezno/pull/158