Add large_types_passed_by_value lint

[cauebs]

Creates a new lint that checks for large function parameters passed by value. Types that are Copy were ignored, because I understand they are explicitly marked as being cheap (or just acceptable) to copy. Arrays were excluded from that restriction because they are always Copy, independently of the size, if the elements are Copy. Only Copy types are considered, because if a type is not Copy it cannot be dereferenced, as pointed out by @ebroto, and that would require analyzing the whole function body to check if the argument is moved somewhere else. self and mut parameters are also skipped.

I refactored trivially_copy_pass_by_ref and the new lint into a new pass_by_ref_or_value module, since both share most of their implementations, as was pointed out to me in #4499.

Some questions that remain:
1. Should self be disregarded for this lint?
2. Should we special case types like Vec and String when suggesting changes? (to slices and &str)
3. What should be the default size limit?
4. Are there any special cases I'm missing?

I ask the maintainers to add the hacktoberfest-accepted label if this PR is decent, even if there are some minor details to work out, but I do intend to stick around and finish the job.

Fixes #4499

changelog: Add new lint [large_types_passed_by_value]

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @matthiaskrgr (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[ebroto]

Thanks for your contribution to Clippy! I've left some remarks.

About your open questions:

1. I think we should exclude self as you suggest because it's a well-known pattern to consume a value, regardless of the efficiency.
2. Vec and String should never trigger the lint as they are quite small in the stack (and are not Copy, see my other comment).
3. and
4. I hope I've answered those in the review itself.

Also, the empty stdout file should be removed.

---

cc @flip1995 if you have the time/energy, I would not mind another pair of eyes on this, as some of my suggestions are quite opinionated :)

[ebroto]

Also, FYI we should fix the dogfood test. Hopefully after the suggestions are applied there should be less (if anything) to modify.

[flip1995]

I ask the maintainers to add the hacktoberfest-accepted label if this PR is decent, even if there are some minor details to work out, but I do intend to stick around and finish the job.

That shouldn't be necessary. PRs are automatically accepted in this repo:

PRs count if:
Submitted during the month of October AND 
Submitted in a public repo AND (
  The PR is labelled as hacktoberfest-accepted by a maintainer OR
  Submitted in a repo with the hacktoberfest topic AND (            <-- This applies for Clippy
    The PR is merged OR
    The PR has been approved
  )
)

[flip1995]

There's an empty *.stdout file that needs to be removed.

---

About Vec and String: You shouldn't get sizes bigger than 16/24Bytes on 64 bit machines, so they can always be safely passed by value. If someone sets the limit as low as that, there is another lint for &Vec and &String suggesting a slice or &str. So I don't think we need to deal with that here.

[bors]

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

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[cauebs]

Ok, I think I addressed all your suggestions! Thanks a lot for the thorough feedback, @ebroto and @flip1995, I learned a lot more than I expected with this PR.

Let me know if there's anything else to improve here, but I might only work on it again next weekend.

[ebroto]

Only a small change and some tests to add, and this should be ready to merge!

Also, could you rebase to get rid of the merge commits and squash to avoid intermediate commits?

[ebroto]

@bors r+

Thanks for your work on this lint!

[bors]

📌 Commit e8731a9 has been approved by ebroto

[bors]

⌛ Testing commit e8731a9 with merge 5c78d26...

[bors]

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: ebroto
Pushing 5c78d26 to master...

[cauebs]

And thank you guys for the feedback and help!