Add large_types_passed_by_value lint
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`]
Refactor trivially_copy_pass_by_ref and the new lint into pass_by_ref_or_value module
Update stderr of conf_unknown_key test
Rename lint to large_types_passed_by_value
Increase `pass_by_value_size_limit` default value to 256
Improve rules for `large_types_passed_by_value`
Improve tests for `large_types_passed_by_value`
Improve documentation for `large_types_passed_by_value`
Make minor corrections to pass_by_ref_or_value.rs suggested by clippy itself
Fix `large_types_passed_by_value` example and improve docs
pass_by_ref_or_value: Tweak check for mut annotation in params
large_types_passed_by_value: add tests for pub trait, trait impl and inline attributes
When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.
```rust
trait Foo {
#[allow(unused_attributes)] #[inline] fn first();
#[inline] #[allow(unused_attributes)] fn second();
}
```
However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).
Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.
This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:
* The `HasAttr` impl for `StmtKind` now returns attributes for
`StmtKind::Item`, treating it just like every other `StmtKind`
variant. The only place relying on the old behavior was macro
which has been updated to explicitly ignore attributes on item
statements. This allows the `unused_doc_comments` lint to fire for
item statements.
* The `early` and `late` lint visitors now activate lint attributes when
invoking the callback for `Stmt`. This ensures that a lint
attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
sibiling attributes on an item statement.
For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR #78306
We also update the documentation to note that the remediations are
different for `std` and `no_std` crates.
Signed-off-by: Joe Richey <joerichey@google.com>
Add more infomation about LintStore registration
Backstory: I somehow missed the fact that I needed to register a lint pass in order for it to run, and I spent some time confused until I figured it out. So I wanted to make it clear that a missing `register_(early|late)_pass` call is a likely cause of a lint not running.
changelog: none
Identical arguments on assert macro family
Lint when identical args are used on `assert_eq!`, `debug_assert_eq!`, `assert_ne!` and `debug_assert_ne!` macros.
Added to the lint `eq_op`.
Common functions added to `utils/higher.rs`
Fixes: #3574Fixes: #4694
changelog: Lint on identical args when calling `assert_eq!`, `debug_assert_eq!`, `assert_ne!` and `debug_assert_ne!` macros
Suggest a compatible shell for setup-toolchain.sh
setup-toolchain.sh uses "[[" which is a bash builtin, but the guide
suggests running it with sh. On Ubuntu, /bin/sh points to dash and
running the script fails.
---
*Please keep the line below*
changelog: none
Backstory: I somehow missed the fact that I needed to register a lint pass in order for it to run, and I spent some time confused until I figured it out. So I wanted to make it clear that a missing `register_(early|late)_pass` call is a likely cause of a lint not running.
BTreeMap: refactor Entry out of map.rs into its own file
btree/map.rs is approaching the 3000 line mark, splitting out the entry
code buys about 500 lines of headroom.
I've created this PR because the changes I've made in #77438 will push `map.rs` over the 3000 line limit and cause tidy to complain.
I picked `Entry` to factor out because it feels less tightly coupled to the rest of `BTreeMap` than the various iterator implementations.
Related: #60302
