Give parser fuzzing some TLC

* The header + expr fuzzers can both be run again (header fuzzer had regressed).
* I ran the expr fuzzer for ~60 seconds with no additional panics uncovered
* "tab_crash" hit supposedly unreachable code in blankspace.rs - and I went to the liberty of dramatically simplifying all that code, rather than just trying to fix the bug
* Other failures were straight-forward error cases that should have been handled (and passed up the chain) instead of panicking
This commit is contained in:
Joshua Warner 2022-12-07 21:45:02 -08:00
parent 521afce1f4
commit 5f29402297
No known key found for this signature in database
GPG key ID: 89AD497003F93FDD
15 changed files with 176 additions and 475 deletions

View file

@ -0,0 +1 @@
Expr(InParens(End(@3), @0), @0)

View file

@ -0,0 +1,2 @@
(@,B
.e:

View file

@ -0,0 +1 @@
Expr(Pattern(NotAPattern(@3), @3), @0)

View file

@ -0,0 +1 @@
SourceError { problem: Space(HasMisplacedCarriageReturn, @1), bytes: [35, 13, 12, 9, 65] }

View file

@ -0,0 +1 @@
# A

View file

@ -0,0 +1 @@
Expr(TrailingOperator(@2), @0)

View file

@ -166,8 +166,12 @@ mod test_parse {
fail/record_type_open.expr,
fail/record_type_tab.expr,
fail/single_no_end.expr,
fail/tab_crash.header,
fail/tag_union_end.expr,
fail/tag_union_lowercase_tag_name.expr,
fail/trailing_operator.expr,
fail/expr_to_pattern_fail.expr,
fail/alias_or_opaque_fail.expr,
fail/tag_union_open.expr,
fail/tag_union_second_lowercase_tag_name.expr,
fail/type_annotation_double_colon.expr,