Opt mssql-odbc into the workspace lint configuration - #476
Conversation
mssql-odbc was the only workspace member without a [lints] section, so it inherited none of the workspace lints. The crate predates the lint setup: the infrastructure landed in 523cf5f and opted in the four members that existed then, and mssql-odbc arrived later in 5d375af as an import from a separate codebase. This exempted it from unexpected_cfgs and the three active clippy lints, which are the async-correctness rules -- await_holding_lock, await_holding_refcell_ref and large_futures -- on a heavily async crate. The gap was easy to miss because `cargo clippy -p mssqlodbc` still reports plenty of warnings; they come from mssql-tds as a path dependency, so the raw count looks healthy. No new warnings result, so this is purely closing the gap. Fixes #475 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
📊 Code Coverage Report
Diff CoverageDiff: main...HEAD, staged and unstaged changesNo lines with coverage information in this diff. 🔗 Quick Links |
There was a problem hiding this comment.
🟢 Approval recommended
The manifest change is correct, scoped, and consistent with other workspace members.
Pull request overview
Opts mssql-odbc into the workspace lint configuration, aligning it with other workspace crates.
Changes:
- Enables inherited Rust and Clippy workspace lints.
- No runtime or API changes.
File summaries
| File | Description |
|---|---|
mssql-odbc/Cargo.toml |
Enables workspace lint inheritance. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Balanced
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
ttk (Theekshna)
left a comment
There was a problem hiding this comment.
Unattended run — no findings. This is a 3-line Cargo.toml-only change ([lints]\nworkspace = true for mssql-odbc), no source touched.
Verified:
git diffagainst the merge-base matches the PR's own reported stats exactly (3/0/1 file).- The lint set the PR claims mssql-odbc was missing —
unexpected_cfgs,await_holding_lock,await_holding_refcell_ref,large_futures— matches[workspace.lints]in the rootCargo.tomlexactly; every other clippy lint listed there is commented out, so nothing else is newly enabled. - Ran
cargo clippy -p mssqlodbc --all-targets --offlineat this head: zero warnings, confirming the PR's "zero new warnings" claim rather than trusting it. - No merge-conflict markers;
baseRefName(main) matches the PR's target.
msodbcsql parity: N/A, no ODBC behavior touched. Test sufficiency: N/A for a lint-config change — the clippy run above is the applicable verification and it passed clean. Divergences: N/A. PR description: matches the diff exactly, linked to #475, checklist claims consistent with the change's scope. No AI slop — no new comments or prose added.
CI: Azure DevOps validation still running on this head (build 171909) at review time; copilot-pull-request-reviewer[bot] already recommended approval.
| Category | Count |
|---|---|
| Blocking | 0 |
| Suggestion | 0 |
| Nit | 0 |
Description
mssql-odbcwas the only workspace member without a[lints]section, so it inherited none of the workspace lint configuration. This adds the two lines that opt it in:Why it was missing. The crate predates the lint setup.
523cf5f7(2026-04-30) added[workspace.lints]and opted in the four members that existed at the time;mssql-odbcarrived later, on 2026-07-08 via5d375afc, as an import from a separate codebase.git log -S'[lints]' -- mssql-odbc/Cargo.tomlreturns nothing — the section was never there.[workspace.lints]is a definition table, not an application table. Members inherit only via an explicit[lints] workspace = true, the same opt-in pattern as[workspace.dependencies].What it was exempt from.
unexpected_cfgs, plus the three currently-active clippy lints —await_holding_lock,await_holding_refcell_refandlarge_futures. Those are the async-correctness rules (deadlock and oversized-future detection), andmssql-odbcis a heavily async crate that boxes future state deliberately, so it is an unfortunate one to have exempt.Why it went unnoticed.
cargo clippy -p mssqlodbcstill emits plenty of warnings, but they all originate inmssql-tdsas a path dependency. A raw warning count looks healthy and hides the gap completely — attributing warnings by file path via--message-format=jsonis what surfaces it.Verification
Confirmed the lints now actually reach the crate, by inspecting the rustc invocation (
cargo clippy -p mssqlodbc -v):None of these were passed before this change. Zero new warnings result, so this is purely closing the gap rather than a behaviour change — no source files are touched.
Follow-up, deliberately not in this PR
The other 35 lints in
[workspace.lints.clippy]remain commented out workspace-wide. For sizing,mssql-odbcalone would emit 682 warnings in production code (--lib) and 3,351 including tests if all 38 were switched on.undocumented_unsafe_blocks(1,786) andunwrap_used(999) are 83% of that, and everyunwrap_usedhit is in test code. Those numbers are recorded in #475 so the staged lints can be adopted per-lint rather than all at once.Related Issues
Fixes #475
Checklist
cargo bfmtpassescargo bclippypassescargo btestpasses — 3,116/3,120 unit tests pass, allmssqlodbctests green. The 4 failures are the pre-existingcertificate_validatorfixture tests (they needmssql-tds/tests/test_certificates/generate_certs.sh); integration suites need a.envwith a live server. Both are environmental and fail identically onmain.