New lint: same_name_method

[lengyijun]

changelog: [`same_name_method`]
fix: #7632

It only compares a method in impl with another in impl trait for
It doesn't lint two methods in two traits.

I'm not sure my approach is the best way. I meet difficulty in other approaches.

[rust-highfive]

r? @llogiq

(rust-highfive has picked a reviewer for you, use r? to override)

[llogiq]

Apart from making this a restriction lint, I think this looks merge-worthy. I don't care too much about struct names in tests.

[lengyijun]

Thx! I have removed the todos.
Although not satisfied with restriction, but being accepted is also a good start for this lint.

[llogiq]

What's your take on restriction vs. pedantic? Why would you not be satisfied with the former?

[lengyijun]

I have no deep insight into the category of lint. Please help we with this hard decision !
I just want this lint can be used more and get more feedback.

[llogiq]

The idea behind pedantic is to group lints that are deemed beneficial to code style, but have enough false positives not to warn by default. restriction lints are for things that are not universally seen as problematic, but may be in some contexts.

As I don't see how your lints could have false positives, yet depending on the context people may choose to ignore it, this fits the restriction category somewhat better than pedantic.

[lengyijun]

I agree on restriction now.

[llogiq]

r=me with the changed lint category 👍

[lengyijun]

@llogiq

[llogiq]

Thank you @lengyijun ! @bors r+

[bors]

📌 Commit e2cdaec has been approved by llogiq

[bors]

⌛ Testing commit e2cdaec with merge ed7a82e...

[bors]

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: llogiq
Pushing ed7a82e to master...

[Zenithsiz]

I'm not sure this is the correct place to comment, as it's already closed, but I feel as if this lint shouldn't trigger if the impl Type function has less arguments than the impl Trait for Type one (given all other parameters are the same).
I use that pattern when an extra unneeded argument is supplied by the trait that I don't require for the implementation. This allows other types to call the inherent function without providing the unneeded argument that won't be used any way.

Example:

trait T {
  fn do(&self, a: u32, b: u32);
}

struct A;

impl A {
  fn do(&self, a: u32) { ... }
}

impl T for A {
  fn do(&self, a: u32, _b: u32) { Self::do(self, a) }
}