#92

development

update started from.

fixes issue 91

"assertion failure with ambiguous LALR compiles"
hammer/hammer#91

i was trying to find out why the test suite suddenly insisted on being so
noisy. turns out glib now does TAP by default and all messages get printed,
--verbose or not. the old mode is considered deprecated.

cf.
https://en.wikipedia.org/wiki/Test_Anything_Protocol
https://gitlab.gnome.org/GNOME/glib/commit/ad175766575b23be920f41cdb1c350447c743347
https://gitlab.gnome.org/GNOME/glib/commit/19aafc4ca4dba2b63d24f01d23890ff30ef9b133

this omission has nagged me a number of times and i think it must have been a
simple oversight.

this way the assert will fire from the user's code rather than the one in
glue.c:h_seq_index() which is not informative without a stack trace.

also includes commented-out tests for functionality that i discovered we never
provided, namely position and length information at the granularity of
HParsedTokens. at the moment, these fields always seem to be 0. we should
probably fix that or get rid of them. in the latter case it might make sense
to move this information to HParseResult, so the user can get access to it via
h_action() as needed.

the regex backend already returned 2 for an internal failure, contrary to
documentation, so this mainly brings the latter in line with existing behavior.

at the same time, fix a bug: h_compile would previously return "false" (0) on
exceptions (longjmp).

make use of our new freedom to signal different error conditions from the
context-free backends, notably "incompatible combinator" vs. "unresolvable
conflict".

Provide an alternate interface to the arena allocator to avoid wasting time on unnecessary calls to memset()

Eliminate unnecessary hash computations in the packrat backend (roughly 2.5x speed in one benchmark)

A working h_drop_from which rewrites its underlying sequence as a sequence containing some ignored parsers.

also allow NULL argument for unamb_sub to mean default

In `h_sequence__ma` the same bug occurs, and it manifests as a crash
in the same way, so I've added a test for it.  In `h_permutation__ma`
it evidently exists in the same form, but I haven't figured out how to
reproduce it; in that case I added a fix to the implementation, but no
test.

I committed the fix for bug #19 without a test because I didn't know
how our test worked yet; here's a test.

A somewhat more desirable way to do this would be to commit the
test *first*, marked as "incomplete" with `g_test_incomplete()` (an
expected failure).  However, `g_test_incomplete()` does not handle
segfaults!  There's no way to mark a segfaulting test as an "expected
segfault".  So if you want to verify that this test reveals the bug,
you'll need to `git show thiscommit | patch -p1` or something, in a
tree that doesn't have the fix applied.  Or you can comment out the
fix, I guess.