Severity-colored, location-aware violation output - #1483
Merged
Gbangbolaoluwagbemiga merged 1 commit intoAug 27, 2026
Merged
Conversation
…1461, HyperSafeD#1458) Both issues' file pointers (tooling/sanctifier-core/src/analyzer.rs, tooling/sanctifier-core/src/rules/s001.rs) don't exist in this repo -- Analyzer actually lives in sanctifier-core/src/lib.rs, and S001 is the AUTH_GAP finding code implemented in rules/auth_gap.rs (finding_codes.rs). Neither file does any output formatting, though: every rule's violations (S001/auth_gap included) already flow through one shared place -- analyze.rs's text-output loop -- which is the actual, real location of "error formatting" for this CLI, and where this fix lands. That loop printed every violation with the same hardcoded red arrow regardless of severity, and silently dropped v.location (the fn/line context every rule already computes) from the output entirely. Now colors the arrow by severity (critical/error=red+bold, high=magenta, warning=yellow, info=cyan) and includes file:location in the printed line. Used colored (already a sanctifier-cli dependency) rather than adding miette: sanctifier-core is also compiled to WASM (sanctifier-wasm), and miette's terminal/span-oriented design isn't a good fit for a library crate with no source-span data on RuleViolation to begin with -- flagging that as a deliberate substitution, not an oversight. Verified with `cargo check` (tooling/sanctifier-cli): passes cleanly. Closes HyperSafeD#1461 Closes HyperSafeD#1458
|
@boluwacodes Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
|
@boluwacodes is attempting to deploy a commit to the gbangbolaoluwagbemiga's projects Team on Vercel. A member of the Team first needs to authorize it. |
Gbangbolaoluwagbemiga
merged commit Aug 27, 2026
872a4b1
into
HyperSafeD:main
15 of 26 checks passed
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
2 participants
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.
Summary
`tooling/sanctifier-core/src/rules/s001.rs`. `Analyzer` actually lives in
`sanctifier-core/src/lib.rs`; S001 is the `AUTH_GAP` finding code, implemented in
`rules/auth_gap.rs`. Neither file does any output formatting — every rule's violations
(auth_gap/S001 included) already flow through one shared place, `analyze.rs`'s text-output loop,
which is the real location of "error formatting" for this CLI and where this fix lands.
That loop printed every violation with the same hardcoded red arrow regardless of severity, and
silently dropped `v.location` (the fn/line context every rule already computes) from the output
entirely. Now colors the arrow by severity (critical/error = red+bold, high = magenta,
warning = yellow, info = cyan) and includes `file:location` in the printed line.
Used `colored` (already a `sanctifier-cli` dependency) rather than adding `miette`, as the issues
suggested: `sanctifier-core` also compiles to WASM (`sanctifier-wasm`), and `miette`'s
terminal/span-oriented design isn't a great fit for a library crate — `RuleViolation` doesn't
carry source-span data to begin with. Flagging as a deliberate substitution.
Not done in this batch
CONTRIBUTING.md[Maintenance] #1460 (typo fixes in `CONTRIBUTING.md`): read through the file looking for the kind oferrors the issue describes (misspellings, common typo patterns) and didn't find any — the doc
reads as clean. Given the time budget, didn't do a full line-by-line manual proofread beyond
that. Not closing since I can't point to an actual fix.
frontend/pages/index.tsx[Performance] #1456 ("optimize loading states in `frontend/pages/index.tsx`"): same missing-file issue asprior batches (`frontend/pages/` doesn't exist — this is a Next.js App Router project, real
entry is `frontend/app/page.tsx`) — not reached before the stop instruction.
Test plan
dead-code warning in `sanctifier-core`, not touched by this change).
Closes #1461
Closes #1458
Closes #1456
Closes #1460