This commit fixes a bug where the parser could produce a very deeply
nested Hir value beyond the configured nested limit. This was caused by
the fact that the Hir can have some of its nested structures added to it
without a corresponding recursive call in the parser. For example,
repetition operators. This means that even if we don't blow the nest
limit in the parser, the Hir itself can still become nested beyond the
limit. This in turn will make it possible to unintentionally overflow
the stack in subsequent recursion over the Hir value, such as in the
Thompson NFA compiler.

We fix this by checking the nesting limit both on every recursive parse
call and also on the depth of the final Hir value once parsing is
finished but before it has returned to the caller.

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=60608

PR #1107

It turns out that we missed another case where the stack could overflow:
dropping a deeply nested Hir. Namely, since we permit deeply nested Hirs
to be constructed and only reject them after determining they are too
deeply nested, they still then need to be dropped. We fix this by
implementing a custom a Drop impl that uses the heap to traverse the Hir
and drop things without using unbounded stack space.

An alternative way to fix this would be to adjust the parser somehow to
avoid building deeply nested Hir values in the first place. But that
seems trickier, so we just stick with this for now.

This reverts commit 8a8d599 and
includes a regression test, as well as a tweak to a log message.

Essentially, the broadening was improper. We have to be careful when
dealing with suffixes as opposed to prefixes. Namely, my logic
previously was that the broadening was okay because we were already
doing it for the reverse inner optimization. But the reverse inner
optimization works with prefixes, not suffixes. So the comparison wasn't
quite correct.

This goes back to only applying the reverse suffix optimization when
there is a non-empty single common suffix.

Fixes #1110
Ref astral-sh/ruff#7980

This fixes a hole in the validation logic that accidentally permitted a
dense DFA to contain a match state with zero pattern IDs. Since search
code is permitted to assume that every match state has at least one
corresponding pattern ID, this led to a panic.

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=63391

The example shows a succinct way of creating an HIR literal from a
`char` value by first encoding it to UTF-8.

Closes #1114

When we added the WhichCaptures type, we didn't update the CLI to expose
the full functionality. This change does that.

This was suggested [on Discord](https://discord.com/channels/273534239310479360/1120175689124036669/1181401471720370237).

This referenced `Captures::get`, but it should reference
`Captures::name`. This was likely a transcription error
from the docs for the `Index<usize>` impl.

The regex 1.10 release bumped the MSRV to Rust 1.65, so we no longer
need to pin to an older memchr release.

We also bump to `actions/checkout@v4`.

I'm not sure how this one slipped by. Without this, I'd suppose that
no-std support doesn't actually work? Or at least, one would have to
disable the use of both memchr and aho-corasick entirely, since they
depend on std by default. Not quite sure how to test this.

Fixes #1147

Before this commit, Input::new calls haystack.as_ref() twice, once to
get the actual haystack slice and the second time to get its length. It
makes the assumption that the second call will return the same slice,
but malicious implementations of AsRef can return different slices
and thus different lengths. This is important because there's unsafe
code relying on the Input's span being inbounds with respect to the
haystack, but if the second call to .as_ref() returns a bigger slice
this won't be true.

For example, this snippet causes Miri to report UB on an unchecked
slice access in find_fwd_imp (though it will also panic sometime later
when run normally, but at that point the UB already happened):

    use regex_automata::{Input, meta::{Builder, Config}};
    use std::cell::Cell;

    struct Bad(Cell<bool>);

    impl AsRef<[u8]> for Bad {
        fn as_ref(&self) -> &[u8] {
            if self.0.replace(false) {
                &[]
            } else {
                &[0; 1000]
            }
        }
    }

    let bad = Bad(Cell::new(true));
    let input = Input::new(&bad);
    let regex = Builder::new()
        // Not setting this causes some checked access to occur before
        // the unchecked ones, avoiding the UB
        .configure(Config::new().auto_prefilter(false))
        .build("a+")
        .unwrap();
    regex.find(input);

This commit fixes the problem by just calling .as_ref() once and use
the length of the returned slice as the span's end value. A regression
test has also been added.

Closes #1154

This commit exposes `is_fast` and also adds `max_needle_len`
to a prefilter. This is useful for engines implemented outside
of `regex-automata`.

PR #1156

It looks like `dead_code` got a little smarter, and more pervasively,
some new lint that detects superfluous imports found a bunch of them.

Previously, when compiling a Thompson NFA, we were omitting an
unanchored prefix when the HIR contained a `^` in its prefix. We did
this because unanchored prefix in that case would never match because of
the requirement imposed by `^`.

The problem with that is it's incorrect when compiling a reverse
automaton. For example, in the case of building a reverse NFA for `^Qu`,
we should sitll include an unanchored prefix because the `^` in that
case has no conflict with it. It would be like if we omitted an
unanchored prefix for `Qu$` in a forward NFA, which is obviously wrong.

The fix here is pretty simple: in the reverse case, check for `$` in the
suffix of the HIR rather than a `^` in the prefix.

Fixes #1169

This adds a guarantee to the API of the `replace`, `replace_all` and
`replacen` routines that, when `Cow::Borrowed` is returned, it is
guaranteed that it is equivalent to the `haystack` given.

The implementation has always matched this behavior, but this elevates
the implementation behavior to an API guarantee.

There do exists implementations where this guarantee might not be upheld
in every case. For example, if the final result were the empty string,
we could return a `Cow::Borrowed`. Similarly, if the final result were a
substring of `haystack`, then `Cow::Borrowed` could be returned in that
case too. In practice, these sorts of optimizations are tricky to do in
practice, and seem like niche corner cases that aren't important to
optimize.

Nevertheless, having this guarantee is useful because it can be used as
a signal that the original input remains unchanged. This came up in
discussions with @quicknir on Discord. Namely, in cases where one is
doing a sequence of replacements and in most cases nothing is replaced,
using a `Cow` is nice to be able to avoid copying the haystack over and
over again. But to get this to work right, you have to know whether a
`Cow::Borrowed` matches the input or not. If it doesn't, then you'd need
to transform it into an owned string. For example, this code tries to do
replacements on each of a sequence of `Cow<str>` values, where the
common case is no replacement:

```rust
use std::borrow::Cow;

use regex::Regex;

fn trim_strs(strs: &mut Vec<Cow<str>>) {
    strs
    .iter_mut()
    .for_each(|s| moo(s, &regex_replace));
}

fn moo<F: FnOnce(&str) -> Cow<str>>(c: &mut Cow<str>, f: F) {
    let result = f(&c);
    match result {
        Cow::Owned(s) => *c = Cow::Owned(s),
        Cow::Borrowed(s) => {
            *c = Cow::Borrowed(s);
        }
    }
}

fn regex_replace(s: &str) -> Cow<str> {
    Regex::new(r"does-not-matter").unwrap().replace_all(s, "whatever")
}
```

But this doesn't pass `borrowck`. Instead, you could write `moo` like
this:

```rust
fn moo<F: FnOnce(&str) -> Cow<str>>(c: &mut Cow<str>, f: F) {
    let result = f(&c);
    match result {
        Cow::Owned(s) => *c = Cow::Owned(s),
        Cow::Borrowed(s) => {
            if !std::ptr::eq(s, &**c) {
                *c = Cow::Owned(s.to_owned())
            }
        }
    }
}
```

But the `std::ptr:eq` call here is a bit strange. Instead, after this PR
and the new guarantee, one can write it like this:

```rust
fn moo<F: FnOnce(&str) -> Cow<str>>(c: &mut Cow<str>, f: F) {
    if let Cow::Owned(s) = f(&c) {
        *c = Cow::Owned(s);
    }
}
```

Most regular expression engines don't accept the `{,n}` syntax, but
some other do it (namely Python's `re` library). This introduces a new
parser configuration option that enables the `{,n}` syntax.

PR #1086