Move has_visited check to the top of the loop in backtrack::Bounded::step

[adamcrume]

…pressions

With certain repeated empty expressions similar to (x*)*?, the backtracker can
go into an infinite loop. This change adds the Progress instruction which
requires the engine to make progress to continue matching a repeated
subexpression.

Fixes #375

Note that this was inspired by https://swtch.com/~rsc/regexp/regexp2.html#real (mentioned in HACKING.md), which mentions that a progress instruction can be used to prevent backtracking loops.

[adamcrume]

Whoops, was only running a subset of the tests. Fix on the way...

[BurntSushi]

Sorry that I haven't had a chance to look at this yet, but I'm skeptical of the approach in this PR. The code that re-implements matching semantics in an ad hoc fashion on the AST seems particularly unfortunate.

I haven't given any thought to this, but both RE2 and Go's regexp library have a bitstate backtracker like the one in this crate. Are those regex engines susceptible to this problem? If not, how do they solve it?

[BurntSushi]

In particular, I'd like to understand why the visited logic isn't preventing the infinite loop.

[adamcrume]

has_visited was returning true, so the loop was exiting, but the split instruction had already pushed a job at that point, so step kept getting called again. Moving the has_visited check to above the match statement fixes the problem without any Progress instruction.

[adamcrume]

Does this new change look better? It's certainly smaller in scope and size.

[BurntSushi]

@adamcrume Yes, much nicer! Thank you for doing this work to fix this subtle bug. It is most appreciated! @bors r+

[bors]

📌 Commit 6356d1a has been approved by BurntSushi

[bors]

⌛ Testing commit 6356d1a with merge 30e35a3...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: BurntSushi
Pushing 30e35a3 to master...