Thanks for the heads up. I'll try to dedup them.

While I think the rust regex crate is heavily inspired by RE2 and uses a fairly compatible syntax I don't think there is a goal to be 100% compatible and I would be surprised if there weren't any differences. What I am trying to say is that if we are going to change engines we may as well change to regex. If we are using RE2 for backwards compatibility then this change makes sense.

Does mercurial currently use RE2? If not then can you explain why we don't just use the rust regex crate?

Maybe what we should do is keep the test I proposed, but change the definition of BLOCK_SIZE to be based upon the number of contained i32 instead of size_of.

Ah yes. So my test would be ineffective.

I think it's better. Maybe still a little vauge but I'll let subject experts make that decision.

One last note is why not just put this in HgPath?

I'm not convinced PrettyPrint is the best name. I might call it something more to do with escaping instead of "pretty". However I can't think of anything great.

I see a lot of the functions are here to give optimization hints. In order to make someone non-familiar with the code able to understand it each method should state the contracts that it is making. I am having a really hard time reconciling how the different functions interact and which methods have precedence over each other.

In D7116#104769, @Alphare wrote:

The following comparison shows that for input > 20 bytes, fnv has worse overall performance than xx

I've seen very good results with https://github.com/servo/rust-fnv in the past so it is probably worth including that in the comparison and possibly using it. It is especially good for small keys which seems like a common case in hg.

In D7116#104617, @durin42 wrote:

OOC, have you compared this with the hashbrown crate for perf?

Thanks, looks good.

It looks good overall. I just would like to have a bit more strict definition of what an HgPath can contain and preferably some init-time validation.