Repository navigation
fix: report match counts in --stats for the local-index and brute-force paths - #149
Conversation
There was a problem hiding this comment.
🟡 Changes recommended
Match totals can be incorrect across paths, output modes, and trimmed matches; coverage should be expanded.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Adds match and matched-line totals to local-index and brute-force --stats output.
Changes:
- Tracks totals in
OutputWriter. - Reports totals across search summaries.
- Preserves existing JSON statistics handling.
File summaries
| File | Description |
|---|---|
tgrep-cli/src/search.rs |
Prints totals in local and brute-force summaries. |
tgrep-cli/src/output.rs |
Adds match accounting; currently mishandles multiple paths, non-line modes, and trimmed matches. |
Review details
Suppressed comments (1)
tgrep-cli/src/output.rs:305
- The existing
--statsintegration tests only verify output ordering and do not assert the newly added totals. Please add brute-force and local-index assertions for multiple matches on one line and for a non-line output mode such as--count; a multiple-path case is also needed to catch counter leakage between runs.
pub fn match_totals(&self) -> (u64, u64) {
(self.total_matches, self.total_matched_lines)
- Files reviewed: 2/2 changed files
- Comments generated: 3
- Review effort level: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
@microsoft-github-policy-service agree |
|
Fixed — now counting m.spans.len() (the original match spans) instead of You're right that --files-with-matches, --count/--count-matches, and binary |
There was a problem hiding this comment.
🟡 Changes recommended
Match statistics can be incorrect across several supported search and output modes.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
Suppressed comments (3)
tgrep-cli/src/output.rs:569
- The totals are only updated by
write_match, but several successful local-search output modes return before calling it:-latsearch.rs:1724,-c/--count-matchesatsearch.rs:1729, quiet mode atsearch.rs:1719, and non-JSON binary output atsearch.rs:1742. Those commands now print0 matches (0 matched lines)despite finding matches (for example,--no-index -c --stats). Record theFileMatchestotals before the presentation-specific early returns, with the appropriate mode limits, rather than deriving stats solely from rendered match rows.
self.total_matches += m.spans.len() as u64;
tgrep-cli/src/output.rs:305
OutputWriteris shared across every command-line target (main.rs:1339-1351), so these totals are cumulative, while each local/brute-force target prints a stats line immediately. With two path arguments, the second summary therefore includes matches from the first; server-delegated summaries remain per-target because they count only that response. Reset or snapshot/delta the counters persearch::run, or defer reporting to one invocation-level summary.
pub fn match_totals(&self) -> (u64, u64) {
(self.total_matches, self.total_matched_lines)
tgrep-cli/src/search.rs:1222
- The existing
--statsintegration tests only assert output ordering, so the newly reported values are untested. Add local-index and--no-indexassertions covering multiple matches on one line, multiple positional paths, count/file-only output, inverted matches, and a multiline match; these cases exercise the counter semantics and would catch the incorrect totals above.
let (matches, matched_lines) = writer.match_totals();
eprintln!(
"Search completed in {:.1}ms: {matches} matches ({matched_lines} matched lines)",
elapsed.as_secs_f64() * 1000.0
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Balanced
|
thanks North research (@thecolourfoundation) for contributing, could you resolve the CCR comments? |
Count original matches independently of output modes and scope text statistics to each search root. Carry optional per-file server totals while preserving existing match rows and JSON output semantics. Co-authored-by: Copilot App <[email protected]>
There was a problem hiding this comment.
🟡 Changes recommended
Binary totals can include content past the NUL cutoff, and files-only server stats can create match-proportional RPC payloads.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
- Files reviewed: 5/5 changed files
- Comments generated: 2
- Review effort level: Balanced
Return one compact marker per matching file when files-only statistics are requested, retaining exact totals and binary markers without rendering match rows. Add bounded-payload regressions and clarify binary byte-count semantics. Co-authored-by: Copilot App <[email protected]> Copilot-Session: 9676a521-6e9e-45aa-879e-e00d51714daa
There was a problem hiding this comment.
🔵 Needs a closer look
Legacy-server fallbacks can report incorrect files-only and quiet totals.
Review details
Suppressed comments (1)
Previously missed (1) — in code that hasn't changed since the last review.
tgrep-cli/src/search.rs:1122
- When an older server omits
file_stats, its rendered rows are insufficient for-l --statsand-q --stats. The oldfiles_onlypath clamps every file to one matching line, while quiet sendsmax_count: 1per file but receives rows from every matching file; counting all those rows therefore undercounts files-only searches and overcounts quiet searches versus the local and new-server paths. Iffile_statsis absent for either mode, retry without truncation and apply first-file filtering, or bypass the server rather than printing an incorrect total.
- Files reviewed: 5/5 changed files
- Comments generated: 0 new
- Review effort level: Balanced
Co-authored-by: Copilot App <[email protected]> Copilot-Session: 9676a521-6e9e-45aa-879e-e00d51714daa
There was a problem hiding this comment.
🔵 Needs a closer look
The legacy-server fallback can report incorrect totals because rendered rows do not preserve complete match statistics.
Review details
Suppressed comments (1)
Previously missed (1) — in code that hasn't changed since the last review.
tgrep-cli/src/search.rs:1122
- This fallback cannot reconstruct the promised totals from an older server response. Before this change, a files-only request forced
max_countto 1, so an upgraded CLI connected to a still-running old daemon reports only the first matching line for-l --stats(and multiline rows can likewise split one regex match across lines). Detect the missingfile_statsbefore rendering and retry via the local path, or otherwise treat that server as incompatible, rather than emitting an incorrect total.
- Files reviewed: 6/8 changed files
- Comments generated: 0 new
- Review effort level: Balanced
|
Thanks for picking this up and pushing it the rest of the way — appreciate |
--statsreports a match count on the server-delegated search path, but thelocal-index and brute-force paths — which cover the common case of an
unindexed or single-machine search — only ever printed timing, with no match
or line count. Confirmed against current
main:vs. the server path's
This adds a format-agnostic match/line counter to
OutputWriter(separatefrom the JSON
Stats/file_statsaccounting already used for--json'ssummaryevent, so that path is untouched), and reports it from all three--statsprint sites insearch.rs. All three now agree:Related to #145 — #146 fixed the print-ordering half of that issue; this
addresses the "more stats like
rgsupplies" half, which was still openafter #146.
Tested:
cargo test --workspace(623 tests, 0 failures), manual verificationof all three search paths against ripgrep-style stats output.