make noop_method_call warn by default

[fee1-dead]

r? @compiler-errors

[erikdesjardins]

This note doesn't really make sense. Vec<i32>::clone also returns the same type it's called on, but that doesn't mean it does nothing. (Alternatively, if you argue that autoref means Vec::new().clone() actually calls clone on &Vec, then clone never returns the type it's called on and the note is still incorrect, because then we're calling clone on &&PlainType<u32>)

I would suggest something like:

Suggested change

	= note: the type `&PlainType<u32>` which `clone` is being called on is the same as the type returned from `clone`, so the method call does not do anything and can be removed
	= note: the type `PlainType<u32>` does not implement `Clone`, so calling `clone` on `&PlainType<u32>` clones the reference, which does not do anything and can be removed

[bors]

☔ The latest upstream changes (presumably #111348) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[compiler-errors]

Does bumping a lint from allow -> warn need an fcp or anything? Implementation looks fine now -- I like the new rewording too.

[fee1-dead]

Not sure about whether a fcp is needed.

cc @rust-lang/compiler-contributors

[RalfJung]

cc @rust-lang/compiler-contributors

(That's a huge ping group with more than 40 people, most of whom do not have FCP power. It's probably not what you wanted to ping here.)

[fee1-dead]

It's the group that gets pinged for MCPs so I pinged.

[oli-obk]

This lint was made allow-by-default in the original PR, but there was never the proposed follow up to make it warn-by-default. I think it was mostly allow-by-default to make it easier for clippy to transition?

This implemented the lint proposed in the following lang-team MCP: rust-lang/lang-team#67

The lang team would like to see a crater run with this lint denied to judge its effects on existing code.

[fee1-dead]

experiment PR now up at #112160

[fee1-dead]

experiment completed. Should I add a suggestion to the diagnostic?

[fee1-dead]

Marking as S-waiting-on(-lang)-team

[oli-obk]

experiment completed. Should I add a suggestion to the diagnostic?

Please summarize the crater results. You can then add the lang team nominated label so their triage picks it up

[fee1-dead]

I have added a suggestion.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[compiler-errors]

@bors r+

[bors]

📌 Commit 2a76c57 has been approved by compiler-errors

It is now in the queue for this repository.

[bors]

⌛ Testing commit 2a76c57 with merge 4734ac0...

[bors]

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 4734ac0 to master...

[rust-timer]

Finished benchmarking commit (4734ac0): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	3.9%	[3.9%, 3.9%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.6%	[-0.6%, -0.6%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.7%	[-0.6%, 3.9%]	2

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 651.453s -> 650.829s (-0.10%)