Repository navigation
-U --count-matches counts one cross-line match once per covered line and disagrees with --stats #188
Description
Summary
With -U/--multiline, --count-matches counts the per-line pieces of a match instead of the original regex match. A single match spanning two lines is reported as 2, while ripgrep reports 1.
For a file containing hello\nworld\n, the pattern hello\nworld matches exactly once. tgrep's --stats correctly reports 1 matches (2 matched lines), but the same command prints 2 for --count-matches.
This happens with --no-index, with the on-disk index, and through tgrep serve.
Related to #185: the adjacent-match example from that issue now correctly counts two matches after #187. This report concerns one match spanning multiple lines.
Reproduce
mkdir repro && cd repro
printf 'hello\nworld\n' > a.txt
tgrep --no-index -U --count-matches -- 'hello\nworld' a.txt
rg -U --count-matches -- 'hello\nworld' a.txt
tgrep --no-index -U --count-matches --stats -- 'hello\nworld' a.txt
# Controls: one single-line match, then two independent matches
tgrep --no-index -U --count-matches -- 'hello' a.txt
tgrep --no-index -U --count-matches -- 'hello|world' a.txt| Query | Actual: tgrep | Expected: rg 15.1.0 |
|---|---|---|
-U --count-matches 'hello\nworld' |
2 |
1 |
-U --count-matches --stats 'hello\nworld' |
stdout: 2; stats: 1 matches (2 matched lines) |
stdout: 1 |
-U --count-matches 'hello' |
1 |
1 |
| `-U --count-matches 'hello | world'` | 2 |
All commands above exit 0.
The indexed query gives the same incorrect count:
tgrep index .
tgrep -U --count-matches -- 'hello\nworld' .For the server path, start tgrep serve --no-watch . in another terminal and repeat the directory query. Adding --stats confirms (via server) and still reports one match while stdout counts two.
Environment
- tgrep 1.1.0, built from b614b8c (current
main, including Fix search compatibility bugs and Linux RSS test #187) - Release build:
cargo build --release --locked -p tgrep-cli - rustc 1.95.0 (59807616e 2026-04-14)
- Windows 11 Pro (build 28000); the counting code involved is platform-independent
- ripgrep 15.1.0, checked with its default engine and
--pcre2 - The incorrect tgrep count was confirmed across scan, local-index, and server paths with both
--engine defaultand--engine pcre2
Cause
In multiline mode, FileMatches::find collects the original spans, then passes them to group_spans_by_line. It already saves the original match count in match_totals:
tgrep/tgrep-cli/src/matching.rs
Lines 766 to 768 in b614b8c
group_spans_by_line clips each original span onto every line it covers. The single (0, 11) span for hello\nworld becomes one span on the hello line and one on the world line.
However, FileMatches::match_count sums the spans in those per-line hits. The scan and local-index output path uses that method for --count-matches:
Lines 2119 to 2125 in b614b8c
The server client independently reconstructs the count by summing spans from each returned line, producing the same result:
Lines 1224 to 1233 in b614b8c
Server stats instead use the original match_totals, which explains the disagreement:
Lines 2170 to 2179 in b614b8c
Possible fix
Use the original regex match count, after applying the search limit and before splitting spans for presentation, for non-inverted multiline --count-matches. The local path already retains that count in FileMatches::match_totals. Carry the original per-file count through server responses independently of --stats, rather than reconstructing it from rendered lines. Preserve the existing behavior for inverted matching.
The existing stats_multiline_counts_original_matches_before_rendering test includes --count-matches, but it asserts the stats totals and output parity with/without --stats, not the expected stdout count.
A regression could assert that hello\nworld over hello\nworld\n prints 1 with --count-matches, with and without --stats, across scan, local-index, and server paths. The single-line, independent-match, and adjacent-match controls should retain their existing counts.
Activity