rust-lang
Make `trivial-copy-size-limit` target independent
Fixes https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Ambiguous.20default.20value.20for.20.60trivial-copy-size-limit.60
The current situation is
| Target width | trivial-copy-size-limit |
|---|---|
| 8-bit | 2 |
| 16-bit | 4 |
| 32-bit | 8 |
| 64-bit | 8 |
Since practically speaking it's almost always 8, let's go with that as the unconditional default to make it easier to understand
changelog: [trivial-copy-size-limit] now also defaults to 8 on 8-bit and 16-bit targets
r? @Jarcho
rustbot has assigned @Jarcho. 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
The original justification for limiting it to eight on 64-bit targets was quite flimsy. It makes (usize, usize) ok on everything but 64-bit targets. This means something like struct S(&'static [u8]) is too big to pass by value, which is rather ridiculous.
It would be nice if the lint could be target independent, but struct sizes already aren't.
This means something like
struct S(&'static [u8])is too big to pass by value
It means it's not small enough to lint, not that it's too big to pass by value. That's a separate config pass-by-value-size-limit
Sorry I had lint/not lint backwards (was half thinking of large_types_passed_by_value). &S would be trigger trivially_copy_pass_by_ref on 32-bit targets, but not on 64-bit targets. Basically fat pointers should behave consistently.
:umbrella: The latest upstream changes (presumably #13286) made this pull request unmergeable. Please resolve the merge conflicts.
:umbrella: The latest upstream changes (possibly d28d2344d000aa96bef729cf408731f952f71fb0) made this pull request unmergeable. Please resolve the merge conflicts.
Changed it to be the width of the target pointer, this halves the limit for smaller targets but keeps 64-bit the same
Increasing 64-bit's limit is also an option, but it led to many more cases being linted