--lint severity control + inline suppression (#399)#428
Merged
Conversation
…on (#399) `--lint` exited 1 on any warning with no escape hatch, so consumer repos — the forcing functions, which run `--lint --json` nonzero-on-warning in CI — had warnings-as-errors and no way to opt out. - `--lint-level error|warning` chooses the exit-1 threshold. `error` makes warnings advisory: still printed and still in `--json`, but exit 0 unless an error-severity diagnostic is present. So CI can surface diagnostics without breaking the build on style warnings. - `# lint: allow <CODE>...` (space/comma-separated, or `all`) silences those codes on its own line and the line below — trailing on the flagged construct or on the line above. Suppressed diagnostics leave both human and `--json` output. Scans raw source (comments are stripped before the AST). This is the suppression escape hatch W016 was waiting on. Per-file `eigs.json` allow-lists stay open on #399 as a contributor on-ramp (needs a JSON reader in the lint path). docs/DIAGNOSTICS.md "Severity control and suppression"; test_lint.sh covers both levels, trailing + above suppression, and no-over-suppression. Suite 2503/2503; ASan clean on the lint path. Advances #399 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
--lintexited 1 on any warning with no escape hatch — so the consumer repos that run--lint --jsonnonzero-on-warning in CI had warnings-as-errors and no opt-out.--lint-level error|warning— the exit-1 threshold.errormakes warnings advisory: still printed and still in--json, but exit 0 unless an error-severity diagnostic is present. CI can surface diagnostics without breaking the build on style warnings.# lint: allow <CODE>...— silences those codes (space/comma-separated, orall) on its own line and the line below, so it works trailing on the flagged line or on the line above:--jsonoutput. Scans raw source, since comments are stripped before the AST.Why now
This is the suppression escape hatch W016 (bare-predicate lint, deferred in #425) was waiting on — a broad lint rule is only safe to ship default-on once consumers can suppress a false-ish positive without pinning a whole file.
Scope
Per-file
eigs.jsonallow-lists remain open on #399 as the contributor on-ramp the issue calls for (it needs a JSON reader wired into the lint path, which pairs naturally with thepkg.eigs/eigs.jsonmachinery).Verification
test_lint.shcovers both levels, trailing + line-above suppression, advisory-still-prints, and no-over-suppression. Suite 2503/2503; ASan clean on the lint path.Advances #399
🤖 Generated with Claude Code