fix: zero_repeat_side_effects generic type needed

[paulmialane]

Fix zero_repeat_side_effects emitting broken suggestions for generic types

Fixes #16474

What's wrong

The zero_repeat_side_effects lint suggests splitting

let mut entries = vec![Entry::default(); 0];

into:

Entry::default();
let mut entries: Vec<Entry<usize>> = vec![];

This works fine for simple types, but breaks when the element type has generic parameters, causing:

error[E0283]: type annotations needed
  --> src/main.rs:10:5
   |
   | Entry::default();
   | ^^^^^ cannot infer type for type parameter `T`

The fix

I was looking to fix this by suggesting let _: T = expr; instead of a bare expr;.

This applies to the let_stmt_suggestion and assign_expr_suggestion code paths (both the curly and non-curly branches).

I think the Node::Stmt case (bare expression statement like vec![f(); 0];) does not need this fix because if T were ambiguous there, the original code would already fail to compile.

Remaining problems

While writting the tests, I realized my implementation introduces a new broken suggestion.

When the element type is defined inside a function (for instance issue_16474(), Ty::to_string emits a path like issue_16474::Entry<usize> which is invalid in the suggestion since issue_16474 is a function, not a module.

I see two different approaches:

1. Detect that the type is defined in a function and only emit a help message.
2. Or find a way to trim the function name in the suggestion.

In both case, I don't really know the best way to do this, and I wanted a reviewer's opinion on the right approach before going further.

Thank you !

changelog: [zero_repeat_side_effects]: fix suggestion causes error for generic types

[rustbot]

r? @dswij

rustbot has assigned @dswij.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: 7 candidates
• 7 candidates expanded to 7 candidates
• Random selection from Jarcho, dswij, llogiq, samueltardieu

[dswij]

@paulmialane I see CI is failing, and the commit message is WIP. Is this ready for review?

[paulmialane]

@dswij Yes, the tests are failing because of the remaining issue I mentioned in my previous message. The work isn't finished yet — I'd love a bit of help to keep going if possible. Thank you!

[dswij]

Apologies for the delay in reviewing. @paulmialane

I've taken a look at the fix, and I think it's easier to detect if the side effect we're calling is part of a generic impl. Then either we:

1. use the resolved generic as part of the suggestion
2. don't emit a suggestion, just emit a help message.

Ideally, we'd implement option 1. Let me know if you need further help