Parsing is slow

[uncomputable]

The PEST parser struggles with series of open brackets that are not closed. This means that the fuzzer runs slow units that take up to hundreds of seconds to parse.

fn n(){ { (s,(( (Ns,(s,(x,(((s,((s,(s,(s,(x,(( {5

fn fnnfn(MMet:(((sssss,((((((sssss,ssssss,ss,((((((sssss,ss,((((((sssss,ssssss,ss,((((((sssss,ssssss,((((((sssss,sssssssss,(((((((sssss,sssssssss,(((((ssss,((((((sssss,sssssssss,(((((((sssss,ssss,((((((sssss,ss,((((((sssss,ssssss,ss,((((((sssss,ssssss,((((((sssss,sssssssss,(((((((sssss,sssssssss,(((((ssss,((((((sssss,sssssssss,(((((((sssss,sssssssssssss,(((((((((((u|(

fn nf224(jet:J ){{{{{{{{{{{{ {     {{ {  { {   {{ 

Maybe the grammar file that I wrote contains anti patterns that needlessly slow down the parser. So far I haven't found a resource on these, but I will keep looking and I will try to rewrite the file.

It could also be that the PEST parser is inherently slow. In this case, we will have to move to a different parser. However, I will hold off on such a massive change until more important work has been done.

[stringhandler]

I think this can be retested and closed since #185 has been merged. cc @delta1

[KyrylR]

Will do the retest

[KyrylR]

• The first pathological input from the issue is now fast. The repo already has a regression test for it at src/lib.rs:689, and cargo test fuzz_slow_unit_1 passes.
• Running that first payload through target/release/simc returned parse errors in about 0.35s.
• The second {-heavy payload from the issue body is still noticeably slow: target/release/simc took about 2.54s to reject it.

I would consider this an improvement... though I do not have previous results. I am closing this issue for the time being