regex: make CRLF hack more robust

This commit improves the CRLF hack to be more robust. In particular, in
addition to rewriting `$` as `(?:\r??$)`, we now strip `\r` from the end
of a match if and only if the regex has an ending line anchor required for
a match. This doesn't quite make the hack 100% correct, but should fix most
use cases in practice. An example of a regex that will still be incorrect
is `foo|bar$`, since the analysis isn't quite sophisticated enough to
determine that a `\r` can be safely stripped from any match. Even if we
fix that, regexes like `foo\r|bar$` still won't be handled correctly. Alas,
more work on this front should really be focused on enabling this in the
regex engine itself.

The specific cause of this bug was that grep-searcher was sneakily
stripping CRLF from matching lines when it really shouldn't have. We remove
that code now, and instead rely on better match semantics provided at a
lower level.

Fixes #1095

grep-regex/src/config.rs

@@ -160,6 +160,14 @@ impl ConfiguredHIR {
         non_matching_bytes(&self.expr)
     }
 
+    /// Returns true if and only if this regex needs to have its match offsets
+    /// tweaked because of CRLF support. Specifically, this occurs when the
+    /// CRLF hack is enabled and the regex is line anchored at the end. In
+    /// this case, matches that end with a `\r` have the `\r` stripped.
+    pub fn needs_crlf_stripped(&self) -> bool {
+        self.config.crlf && self.expr.is_line_anchored_end()
+    }
+
     /// Builds a regular expression from this HIR expression.
     pub fn regex(&self) -> Result<Regex, Error> {
         self.pattern_to_regex(&self.expr.to_string())