Consider silencing `struct_field_names` for structs with `derive(Serialize/Deserialize)`

[jyn514]

Summary

Clippy silences struct_field_names for public structs. This is good and makes sense; the field is part of the public API and renaming it would be a breaking change. However, it still emits the lint for structs with derive(Deserialize). I think these should also be silenced, because Serialize and Deserialize are "super public" - not just available to other crates, but to other programs as well.

Lint Name

struct_field_names

Reproducer

I tried this code:

#![warn(clippy::pedantic)]
use serde::{Serialize, Deserialize};

#[derive(Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub(crate) struct Resource {
    pub(crate) id: String,
    pub(crate) name: String,
    pub(crate) resource_group: String,
}

I saw this happen:

warning: field name starts with the struct's name
 --> src/lib.rs:9:5
  |
9 |     pub(crate) resource_group: String,
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#struct_field_names
note: the lint level is defined here
 --> src/lib.rs:1:9
  |
1 | #![warn(clippy::pedantic)]
  |         ^^^^^^^^^^^^^^^^
  = note: `#[warn(clippy::struct_field_names)]` implied by `#[warn(clippy::pedantic)]`

I expected to see this happen: No lint is emitted.

As an aside, the lint stops firing if i remove id or name, which seems quite odd.

Version

clippy 0.1.75 (82e1608d 2023-12-21)
rustc 1.75.0 (82e1608df 2023-12-21)

Additional Labels

No response

[PartiallyUntyped]

@rustbot label +T-macros

[alexis-langlet]

I'll try looking into it.
@rustbot claim

[alexis-langlet]

I've done some test and it looks like the struct_field_names is silenced for public structs (as @jyn514 was saying) but not for struct that are public only inside the crate scope: pub(crate).

It looks logical to me but is it really the wanted behavior?

On the other hand, it seems that struct_field_names is never triggered when there is 2 or less fields in the struct.
That's why the lint was not triggered when removing id or name but maybe this should be the subject of another issue.

[alexis-langlet]

As @y21 taught me in #12089, the number of fields required to trigger the lint is actually a feature and not a bug.

So, if I understand everything correctly, the behavior of the lints on the code sample is perfectly normal.

[PartiallyUntyped]

The issue is that this is triggered for structs that derive Serialize and Deserialize, which are likely part of a public API.

So, regardless of the number of fields; if these traits are impl'd or derived, then the lint shouldn't trigger on the basis of those structures representing data across programs.

I think that is reasonable, but maybe it is not desirable? What does everyone think?

@rustbot label +S-needs-discussion

[alexis-langlet]

Sorry, I didn't make myself really clear...
The fact is that this will trigger

#![warn(clippy::pedantic)]
use serde::{Serialize, Deserialize};

#[derive(Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub(crate) struct Resource {
    pub(crate) id: String,
    pub(crate) name: String,
    pub(crate) resource_group: String,
}

But this will not

#![warn(clippy::pedantic)]
use serde::{Serialize, Deserialize};

#[derive(Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct Resource {
    pub id: String,
    pub name: String,
    pub resource_group: String,
}

The fact is that it's not silenced because it's only public in the crate scope, so it will never be used in other crates or programs

[PartiallyUntyped]

Visibility shouldn't matter because the struct can be private and at the same time be used to deserialize data sent from across the network.