hubcio opened a new pull request, #3925: URL: https://github.com/apache/iggy/pull/3925
Two classes of warning were accumulating unseen. The doctest leg ran cargo doc with no gate and stayed green through 69 rustdoc diagnostics across 20 crates; broken intra-doc links are the costly ones, since they render as plain text and the docs quietly lose their navigation. Separately, the clippy leg denies warnings but runs with --all-features while the test legs build at default features, so a warning that only shows up when a feature is off was invisible - that is how four dead_code findings in the integration test binary sat in CI output. RUSTDOCFLAGS closes the first and is cache-safe: it enters the fingerprint of doc units only, never lib or bin units. For the second the Cargo lints table beat RUSTFLAGS=-D warnings. RUSTFLAGS enters the fingerprint of every unit including registry dependencies, so it forces a full rebuild of the dep tree and would have to be mirrored into coverage-baseline, the sole writer of the shared cargo cache. Measured both ways here: the lints table rebuilt 50 workspace crates and zero registry crates. Eleven crates keep a local [lints.rust] block because cargo refuses to merge an inherited table with the [lints.clippy] they already carry. That makes their nursery = "warn" effectively deny, since rustc resolves the warnings group at emission time and catches anything left at warn whatever the flag order. CI behaviour is unchanged: the clippy leg already appended -D warnings. Most rustdoc fixes drop the link brackets where the target is private and rustdoc has nothing to point at under --no-deps. Widening visibility to satisfy a doc comment is backwards, and --document-private-items would publish the internals of every crate. The dead ci-qemu feature goes with it; nothing has referenced it since the monorepo restructure in 8db64db94. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
