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

1 files changed, 1 insertions, 10 deletions

diff --git a/grep-searcher/src/searcher/core.rs b/grep-searcher/src/searcher/core.rs
index 21dbae37..c56f643d 100644
--- a/grep-searcher/src/searcher/core.rs
+++ b/grep-searcher/src/searcher/core.rs
@@ -424,16 +424,7 @@ impl<'s, M: Matcher, S: Sink> Core<'s, M, S> {
         }
         self.count_lines(buf, range.start());
         let offset = self.absolute_byte_offset + range.start() as u64;
-        let linebuf =
-            if self.config.line_term.is_crlf() {
-                // Normally, a line terminator is never part of a match, but
-                // if the line terminator is CRLF, then it's possible for `\r`
-                // to end up in the match, which we generally don't want. So
-                // we strip it here.
-                lines::without_terminator(&buf[*range], self.config.line_term)
-            } else {
-                &buf[*range]
-            };
+        let linebuf = &buf[*range];
         let keepgoing = self.sink.matched(
             &self.searcher,
             &SinkMatch {