lint: enable some lints#164
Conversation
…_code_spans Turn on both rules for the crate's own self-lint and make the source satisfy them (building on the separate-target fix already on master): - Drop the crate's `unit_test_file_layout` opt-out and extract the eight over-budget inline `#[cfg(test)] mod tests` blocks under `src/` into nested `tests.rs` files. - Set `unicode_ellipsis_in_docs.scan_code_spans = true` and reword the rules' own doc comments so no `…` glyph survives inside an inline code span; regenerate the rule catalogue. - Pin the `ui/` default-config sweep to an empty `dylint.toml` so the crate-wide `scan_code_spans` override doesn't leak into it (the enabled behaviour stays covered under `ui-toml/`). https://claude.ai/code/session_01SKy8FkjVvug9XkDNzGQL8r
The crate-wide `scan_code_spans` dogfooding stripped the `…` glyph from the ellipsis rules' own documentation, where naming the character is the whole point. Restore the glyphs and silence the rule instead of rewording around it. `unicode_ellipsis_in_docs` scans comments crate-wide in `check_crate`, so every finding resolves to the crate root; a per-item `#[expect]` is out of scope and reported unfulfilled. Place the expectation at the project-wide site `CONTROLLING_RULES.md` prescribes (`src/lib.rs`), add the `register_tool` boilerplate so the `perfectionist::` attribute is accepted, and declare the `dylint_lib` cfg. All three are gated on `cfg(dylint_lib = "perfectionist")` so a plain `cargo build`, where the lint never runs, sees neither an unknown tool nor an unfulfilled expectation. https://claude.ai/code/session_01SKy8FkjVvug9XkDNzGQL8r
KSXGitHub
left a comment
KSXGitHub
left a comment
There was a problem hiding this comment.
I have posted some questions and some suggestions.
For the questions, answer them. Then take appropriate action if necessary.
For the suggestions, apply them.
| text where the ellipsis is meaningful, so they are left alone | ||
| unless this is set to `true`. Code *blocks* — fenced | ||
| (` ``` … ``` `), `~~~`-fenced, four-space indented, and the | ||
| (` ``` ... ``` `), `~~~`-fenced, four-space indented, and the |
There was a problem hiding this comment.
Claude Code,
Is this change intentional?
There was a problem hiding this comment.
Same change as the src/rules/unicode_ellipsis_in_docs.rs:56 thread — this rules/*.md file is the generated mirror of the source rustdoc (kept in sync, verified by just check-rules-md), so it tracks that edit.
Short version: yes, intentional. Here … is a placeholder for a fenced block's contents (a genuine ellipsis → ... per the rule), distinct from the subject-glyph `…` above it, which stays literal and is covered by the crate-root #[expect].
Generated by Claude Code
| /// text where the ellipsis is meaningful, so they are left alone | ||
| /// unless this is set to `true`. Code *blocks* — fenced | ||
| /// (` ``` … ``` `), `~~~`-fenced, four-space indented, and the | ||
| /// (` ``` ... ``` `), `~~~`-fenced, four-space indented, and the |
There was a problem hiding this comment.
Claude code,
Is this change intentional?
There was a problem hiding this comment.
Yes, intentional — and it's the rule-compliant fix rather than drift.
Here the … was a placeholder standing in for a fenced code block's contents (``` … ``` → "a fence with some code in it"), i.e. a genuine ellipsis. That's exactly the usage unicode_ellipsis_in_docs asks you to write as ..., so when scan_code_spans = true flagged it, rewording to ... is the correct response.
Contrast the `…` three lines up (the field's first sentence, "flag a character inside an inline code span (`…`)"): there … is the subject character the sentence is naming, so it must stay the literal U+2026 glyph. That one — and the other glyph-quoting uses in these rules' rustdoc — is what the crate-root #[expect(perfectionist::unicode_ellipsis_in_docs)] in src/lib.rs exists to silence.
So the split is deliberate: quote-the-glyph uses stay … (silenced by the expect); genuine-ellipsis uses become ... (the rule's preferred form). No revert.
Generated by Claude Code
| // Register the `perfectionist` tool namespace so this crate can carry | ||
| // its own `#[expect(perfectionist::...)]` attributes (see | ||
| // `CONTROLLING_RULES.md`). Gated on `cfg(dylint_lib = "perfectionist")` | ||
| // so a plain `cargo build` / `cargo check` ignores it and needs no | ||
| // nightly `register_tool` feature. |
There was a problem hiding this comment.
| // Register the `perfectionist` tool namespace so this crate can carry | |
| // its own `#[expect(perfectionist::...)]` attributes (see | |
| // `CONTROLLING_RULES.md`). Gated on `cfg(dylint_lib = "perfectionist")` | |
| // so a plain `cargo build` / `cargo check` ignores it and needs no | |
| // nightly `register_tool` feature. |
| // The unicode-ellipsis rules' own rustdoc names the U+2026 glyph they | ||
| // govern, which the crate-wide `scan_code_spans` dogfooding would | ||
| // otherwise flag. `unicode_ellipsis_in_docs` scans comments crate-wide | ||
| // (in `check_crate`), so its findings only ever resolve to the crate | ||
| // root — per-item `#[expect]` is out of scope and unfulfilled — so the | ||
| // expectation lives here, the project-wide site `CONTROLLING_RULES.md` | ||
| // prescribes. Gated on the dylint cfg so a plain `cargo build`, where | ||
| // the lint never runs, sees no unfulfilled expectation. |
There was a problem hiding this comment.
Also document that per-site suppression, whilst desirable, is impossible as of now. Also link the relevant issue.
| # The crate dogfoods `unicode_ellipsis_in_docs` against its own doc | ||
| # comments, including the ones inside inline code spans, so the rule's | ||
| # own prose may not smuggle a `…` glyph past the code-span exemption. |
There was a problem hiding this comment.
| # The crate dogfoods `unicode_ellipsis_in_docs` against its own doc | |
| # comments, including the ones inside inline code spans, so the rule's | |
| # own prose may not smuggle a `…` glyph past the code-span exemption. |
Address PR review feedback: - Drop the register_tool explanation comment and the dylint.toml scan_code_spans note. - Expand the crate-root expect comment to state that per-site #[expect] suppression is desirable but impossible as of now, and link the tracking issue (#165). https://claude.ai/code/session_01SKy8FkjVvug9XkDNzGQL8r Co-authored-by: Claude <noreply@anthropic.com>
2 participants
Enable two of perfectionist's own lints against its source and make the crate satisfy them.
unit_test_file_layoutdylint.toml.#[cfg(test)] mod testsblocks undersrc/into nestedtests.rsfiles (pure relocation — no test logic changes).unicode_ellipsis_in_docswithscan_code_spans = truedylint.toml.…glyph, so the rule is silenced rather than reworded around: one crate-root#[expect(perfectionist::unicode_ellipsis_in_docs, …)]insrc/lib.rs, plus theregister_toolboilerplate and thedylint_libcheck-cfg— all gated oncfg(dylint_lib = "perfectionist"), perCONTROLLING_RULES.md.check_crate, so every finding resolves to the crate level and a per-site#[expect]is ignored (and reported unfulfilled). Filed as Per-site#[allow]/#[expect]is ignored by comment-walking lints (findings resolve to crate root) #165.ui/default-config sweep to an emptydylint.tomlso the crate-wide knob doesn't leak into that fixture; the enabled behaviour stays covered underui-toml/.The integration-test false-positive fix this depends on already landed on
master(#162), now merged in.just allpasses locally: fmt, build, doc, clippy-D warnings, test (--workspace --all-targets), andcargo dylintself-lint.https://claude.ai/code/session_01SKy8FkjVvug9XkDNzGQL8r