`cargo::manual_readme` lint's behavior conflicts with `clippy::cargo-common-metadata`

[weihanglo]

Description

Cargo is going to stabilize its own linting system. One of the lints is cargo::manual_readme. The lint suggests leave the package.readme unset if the value can be inferred.

However, this conflicts with the behavior of clippy::cargo_common_metadata, which requires package.readme being set even it is exactly the inferred value.

Given the plan here is slowly migrate Cargo lints in clippy to Cargo, I wonder if we should figure out a solution here to stop the conflict. For example, clippy::cargo_common_metadata stops checking package.readme.

Another approach could that Cargo has a similar lint, though I personally don't feel it worth blocking the stabilization.

Version

rustc 1.100.0-nightly (787af2b8c 2026-08-25)
binary: rustc
commit-hash: 787af2b8c80638c51a4fc8e44f84e6891f243ec7
commit-date: 2026-08-25
host: aarch64-apple-darwin
release: 1.100.0-nightly
LLVM version: 23.1.0

Additional Labels

@rustbot label +T-cargo

[weihanglo]

See #17634 (comment) for a failed example.

[Jarcho]

I would just remove the readme check since we're deprecating this soon™ anyway.

[weihanglo]

#t-clippy > fixing cargo lint errors for clippy @ 💬

@_Weihang Lo|245964 said:

Opened a less controversial rust-clippy#17634 though the new cargo::manual_readme is conflicting with clippy::cargo-common-metadata's behavior 😞

Any suggestion?

Sound like an FP from clippy's side – if the field is not specified, but there exists a README file at a standard location, then there's no reason to lint, as cargo will be able to find the file.

Implementation-wise, I think this will require duplicating the "is there a README in a standard location" check in the clippy lint; but when the lint is moved over to cargo, this duplication can be removed again.

But removing it definitely sounds easier to me 😆.