Add internal lint derive_deserialize_allowing_unknown

[smoelius]

Adds an internal lint to check for #[derive(serde::Deserialize)] without #[serde(deny_unknown_fields)].

Today, if you run Clippy with the following clippy.toml, Clippy will produce a warning, but there will be no accompanying note:

# In the following configuration, "recommendation" should be "reason" or "replacement".
disallowed-macros = [
    { path = "std::panic", recommendation = "return a `std::result::Result::Error` instead" },
]

$ cargo clippy
    Checking a v0.1.0 (/home/smoelius/tmp/a)
warning: use of a disallowed macro `std::panic`
 --> src/lib.rs:2:5
  |
2 |     panic!();
  |     ^^^^^^^^
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#disallowed_macros
  = note: `#[warn(clippy::disallowed_macros)]` on by default

The underlying problem is: the enum that derives serde::Deserialize (DisallowedPathEnum) does not have the attribute #[serde(deny_unknown_fields)].

This lint identifies such problems by checking trait impls. An alternative I considered was to walk clippy_config::conf::Conf directly. However, that would not catch the DisallowedPathEnum case because it is not used in Conf directly.

Just to be clear, no one asked for this. So I hope the maintainers do not mind.

changelog: none

[rustbot]

r? @llogiq

rustbot has assigned @llogiq.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[llogiq]

Why should that only be an internal lint? I could see it as a restriction lint, with some documentation that anything deserialized from user data should have that attribute.

[smoelius]

@llogiq Thank you very much for your comments.

Why should that only be an internal lint? I could see it as a restriction lint,

I had the impression that Clippy preferred to not lint third-party APIs. For example, I recall this comment from 2022: #8434 (review)

Granted, the comment called serde an exception, but the sentiment seemed to be that more such lints were unwanted.

with some documentation that anything deserialized from user data should have that attribute.

I think some might disagree (hence, the reason for the optional attribute). But if the lint is allow by default, that might not matter.

Please tell me if I should proceed with changing the lint's category.

[smoelius]

@llogiq Did you have any further thoughts on this lint?