Summary
plugins/go-format/hooks/go-format.sh's generated-file guard is a bash-string-matching approximation of Go's own ast.IsGenerated detector (the canonical implementation is a full AST/comment parse). Across PR #910's review, an automated Codex pass progressively found and (each time) got a real fix for: a bare marker, a //-style header before the marker, a /* */ block-comment header, an indented block-comment header, and a tab-only blank separator line. All five are now covered by regression tests (cases 5–5h in go-format.test.sh).
This is the expected shape of chasing bash-string-match parity with an AST-based detector: the gap between the two is structural, not a single fixable bug, so further narrow edge cases (particular exotic combinations of build tags, multi-line block-comment nesting, unusual Unicode whitespace, etc.) can keep surfacing indefinitely. The guard is advisory only — the hook never blocks an edit; the worst case for an unhandled shape is goimports reformatting a generated file, visible in the diff, no gate broken.
Decision
Per review discussion on #910: the guard is correct for every realistic generated-file shape a real Go code generator or license-header tool actually produces. Chasing full ast.IsGenerated parity via string-matching would mean either endless narrow patches (churn, not value) or replacing the bash approximation with something that shells out to go for a real parse (a materially bigger design change: latency per edit, a hard go toolchain dependency, - not proposed here).
No further guard patches planned unless a real-world generated file is observed defeating it. This issue exists so a future finding (bot-raised or human-observed) has a place to land without re-litigating the tradeoff, and so the known-limitation is documented rather than implicit.
If revisiting
- Document the specific real-world generated-file shape that defeated the guard (not a synthetic/contrived one).
- Consider whether a
go toolchain shell-out (parsing via go/parser + the actual ast.IsGenerated-equivalent logic, or reusing golang.org/x/tools' own detection helper if one is exported) is now warranted, given the concrete case — that would be the actual fix for structural parity, not another bash pattern.
Summary
plugins/go-format/hooks/go-format.sh's generated-file guard is a bash-string-matching approximation of Go's ownast.IsGenerateddetector (the canonical implementation is a full AST/comment parse). Across PR #910's review, an automated Codex pass progressively found and (each time) got a real fix for: a bare marker, a//-style header before the marker, a/* */block-comment header, an indented block-comment header, and a tab-only blank separator line. All five are now covered by regression tests (cases 5–5h ingo-format.test.sh).This is the expected shape of chasing bash-string-match parity with an AST-based detector: the gap between the two is structural, not a single fixable bug, so further narrow edge cases (particular exotic combinations of build tags, multi-line block-comment nesting, unusual Unicode whitespace, etc.) can keep surfacing indefinitely. The guard is advisory only — the hook never blocks an edit; the worst case for an unhandled shape is goimports reformatting a generated file, visible in the diff, no gate broken.
Decision
Per review discussion on #910: the guard is correct for every realistic generated-file shape a real Go code generator or license-header tool actually produces. Chasing full
ast.IsGeneratedparity via string-matching would mean either endless narrow patches (churn, not value) or replacing the bash approximation with something that shells out togofor a real parse (a materially bigger design change: latency per edit, a hardgotoolchain dependency, - not proposed here).No further guard patches planned unless a real-world generated file is observed defeating it. This issue exists so a future finding (bot-raised or human-observed) has a place to land without re-litigating the tradeoff, and so the known-limitation is documented rather than implicit.
If revisiting
gotoolchain shell-out (parsing viago/parser+ the actualast.IsGenerated-equivalent logic, or reusinggolang.org/x/tools' own detection helper if one is exported) is now warranted, given the concrete case — that would be the actual fix for structural parity, not another bash pattern.