`struct_field_names` triggers when the field name *is* the struct name

Summary

I'm not sure if this is an actual false positive (looks like changing >= to > here might stop it from firing) or it's just not clear to me (even after reading the lint description) why it thinks this is bad.

The lint description says it checks for prefixes / suffixes, and suggests I delete them. That makes sense to me.

But if the field name is the struct name I can't delete the entire name, I'd have to come up with a different one. I could see the point in suggesting that I use a newtype if I had no other fields, but the lint actually won't fire unless I do have other fields, so that doesn't apply either.

That leaves "come up with a different name". If there is value to that, I'd appreciate the lint description explaining it.

Issue #12922 is somewhat related (not just because it's the same lint): the first example there (app in struct App) would also be allowed if this was changed.

Lint Name

struct_field_names

Reproducer

I tried this code:

struct Map {
    map: Vec<Vec<i32>>,
    rows: usize,
    cols: usize,
}

I saw this happen:

warning: field name starts with the struct's name
  --> foo.rs:89:5
   |
89 |     map: Vec<Vec<i32>>,
   |     ^^^^^^^^^^^^^^^^^^
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#struct_field_names

I expected to see this happen:

Either no lint or a better explanation of why this is bad and what I should do instead.

Version

rustc 1.83.0 (90b35a623 2024-11-26)
binary: rustc
commit-hash: 90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf
commit-date: 2024-11-26
host: x86_64-unknown-linux-gnu
release: 1.83.0
LLVM version: 19.1.1

Additional Labels

No response

Start with the struct_field_names implementation in clippy_lints/src/item_name_repetitions.rs at the linked comparison near line 274, then read the lint description and reproduce the Map example. Determine whether the lint should avoid an exact struct-name match or explain the recommendation more clearly; done means the reported behavior and documentation match the intended rule.