Description
The trimleftright linter in pkg/linters/trimleftright/trimleftright.go fires only when a cutset contains a repeated rune (e.g., TrimLeft(s, "foo") triggers because 'o' repeats). This misses the most common real instances of the bug — distinct-char strings like "http", "bar", "abc", "0x", "prefix" — which are exactly the patterns where users confuse TrimLeft/TrimRight with TrimPrefix/TrimSuffix.
The repeated-rune guard adds nothing to false-positive avoidance (the all-alphanumeric guard already handles whitespace character classes) and only removes true positives. The testdata in goodNoRepeatedAlnum canonizes this broken behavior as intentional.
Suggested Changes
- Replace the repeated-rune trigger in
looksSuspiciousCutset with a class-aware discriminator
- Flag all multi-rune alphanumeric cutsets except recognized class idioms (contiguous ranges, hex digits, digit sets like
"0123456789", vowel sets like "aeiou")
- Update
testdata/trimleftright.go to expect diagnostics for TrimLeft(s, "http"), TrimLeft(s, "abc"), TrimLeft(s, "txt")
- Keep
TrimLeft(s, "aeiou"), TrimLeft(s, "0123456789"), TrimLeft(s, "abcdef") as passing (recognized class patterns)
- Or document the narrow scope explicitly in the linter README if intentional
Files Affected
pkg/linters/trimleftright/trimleftright.go (lines 125-146, looksSuspiciousCutset)pkg/linters/trimleftright/testdata/ (update test fixtures)
Success Criteria
TrimLeft(s, "http") is flagged as suspiciousTrimLeft(s, "aeiou") is not flagged (recognized character class)make golint-custom passes with updated tests- False-positive rate does not increase for whitespace character classes
Source
Extracted from Sergo Report: New-Linter Audit - 2026-07-19 #46528
Priority
Medium — The linter misses its primary use case; fixing it will catch real bugs in the codebase
🔍 Task mining by Discussion Task Miner - Code Quality Improvement Agent · 83.8 AIC · ⌖ 5.28 AIC · ⊞ 7K · ◷
Description
The
trimleftrightlinter inpkg/linters/trimleftright/trimleftright.gofires only when a cutset contains a repeated rune (e.g.,TrimLeft(s, "foo")triggers because 'o' repeats). This misses the most common real instances of the bug — distinct-char strings like"http","bar","abc","0x","prefix"— which are exactly the patterns where users confuseTrimLeft/TrimRightwithTrimPrefix/TrimSuffix.The repeated-rune guard adds nothing to false-positive avoidance (the all-alphanumeric guard already handles whitespace character classes) and only removes true positives. The testdata in
goodNoRepeatedAlnumcanonizes this broken behavior as intentional.Suggested Changes
looksSuspiciousCutsetwith a class-aware discriminator"0123456789", vowel sets like"aeiou")testdata/trimleftright.goto expect diagnostics forTrimLeft(s, "http"),TrimLeft(s, "abc"),TrimLeft(s, "txt")TrimLeft(s, "aeiou"),TrimLeft(s, "0123456789"),TrimLeft(s, "abcdef")as passing (recognized class patterns)Files Affected
pkg/linters/trimleftright/trimleftright.go(lines 125-146,looksSuspiciousCutset)pkg/linters/trimleftright/testdata/(update test fixtures)Success Criteria
TrimLeft(s, "http")is flagged as suspiciousTrimLeft(s, "aeiou")is not flagged (recognized character class)make golint-custompasses with updated testsSource
Extracted from Sergo Report: New-Linter Audit - 2026-07-19 #46528
Priority
Medium — The linter misses its primary use case; fixing it will catch real bugs in the codebase