bors [Sat, 24 Oct 2020 23:29:49 +0000 (23:29 +0000)]
Auto merge of #6187 - geoffreycopin:master, r=ebroto
Lint unnecessary int-to-int and float-to-float casts
This is an implementation of a lint that detects unnecessary casts of number literals, as discussed here:
https://github.com/rust-lang/rust-clippy/issues/6116
---
changelog: lint unnecessary as-casts of literals when they could be written using literal syntax.
bors [Sat, 24 Oct 2020 22:31:53 +0000 (22:31 +0000)]
Auto merge of #6135 - cauebs:master, r=ebroto
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`]
bors [Tue, 20 Oct 2020 09:38:38 +0000 (09:38 +0000)]
Auto merge of #6193 - Ryan1729:add-more-LintStore-documentation, r=phansch
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.
bors [Mon, 19 Oct 2020 13:17:07 +0000 (13:17 +0000)]
Auto merge of #6166 - achris:master, r=flip1995
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.
Ryan Wiedemann [Sun, 18 Oct 2020 23:01:57 +0000 (17:01 -0600)]
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.
bors [Fri, 16 Oct 2020 07:45:42 +0000 (07:45 +0000)]
Auto merge of #6178 - josephlr:sync-from-rust, r=phansch
Sync from rust
Fix rustc breakage by running:
```rust
git subtree push -P src/tools/clippy git@github.com:josephlr/rust-clippy sync-from-rust
```
and then adding a commit that runs `cargo dev fmt`
est31 [Wed, 14 Oct 2020 16:42:13 +0000 (18:42 +0200)]
Remove rustc_session::config::Config
The wrapper type led to tons of target.target
across the compiler. Its ptr_width field isn't
required any more, as target_pointer_width
is already present in parsed form.
it took me a while to figure out why `cargo clippy -- -Aclippy::pedantic -Wclippy::items-after-statements` still showed me *all* the lints. At first I thought it was due to the missing spaces in the current example and I debugged that until I stumbled across an issue noting that you have to touch a random file or run `cargo clean` when you're running clippy repeatedly on an unchanged codebase. This PR is an attempt to save the next person some time and also structure the "Allowing/denying lints" section a bit more while we're at it.
Chris Ayoup [Tue, 13 Oct 2020 01:51:05 +0000 (21:51 -0400)]
suggest a compatible shell for running 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 as described fails.
bors [Mon, 12 Oct 2020 13:49:19 +0000 (13:49 +0000)]
Auto merge of #6158 - giraffate:improve_updating_references, r=phansch
Remove the generated files by `update-references.sh` if they are empty
An empty file may be generated by `update-references.sh` and committed as is when creating a patch like https://github.com/rust-lang/rust-clippy/pull/6101#issuecomment-702076508 and https://github.com/rust-lang/rust-clippy/pull/6079#pullrequestreview-496502721. So, I think it would be helpful to add documentation, and automatically remove the generated file if it's empty.
bors [Sat, 10 Oct 2020 13:29:05 +0000 (13:29 +0000)]
Auto merge of #6154 - flip1995:ice_fixes, r=ebroto
Fix two ICEs caused by ty.is_{sized,freeze}
Fixes #6153
Properly fixes #6139
The test case in #6153 is kind of weird. Even removing one of the arguments of the `foo` function prevented the ICE. I think this test case is actually minimal.
bors [Sat, 10 Oct 2020 06:32:32 +0000 (06:32 +0000)]
Auto merge of #5727 - rail-rain:manual_memcpy_with_counter, r=flip1995
Expands `manual_memcpy` to lint ones with loop counters
Closes #1670
This PR expands `manual_memcpy` to lint ones with loop counters as described in https://github.com/rust-lang/rust-clippy/issues/1670#issuecomment-293280204
Although the current code is working, I have a couple of questions and concerns.
~~Firstly, I manually implemented `Clone` for `Sugg` because `AssocOp` lacks `Clone`. As `AssocOp` only holds an enum, which is `Copy`, as a value, it seems `AssocOp` can be `Clone`; but, I was not sure where to ask it. Should I make a PR to `rustc`?~~ The [PR]( https://github.com/rust-lang/rust/pull/73629) was made.
Secondly, manual copying with loop counters are likely to trigger `needless_range_loop` and `explicit_counter_loop` along with `manual_memcpy`; in fact, I explicitly allowed them in the tests. Is there any way to disable these two lints when a code triggers `manual_memcpy`?
And, another thing I'd like to note is that `Sugg` adds unnecessary parentheses when expressions with parentheses passed to its `hir` function, as seen here:
```
error: it looks like you're manually copying between slices
--> $DIR/manual_memcpy.rs:145:14
|
LL | for i in 3..(3 + src.len()) {
| ^^^^^^^^^^^^^^^^^^ help: try replacing the loop by: `dst[3..((3 + src.len()))].clone_from_slice(&src[..((3 + src.len()) - 3)])
```
However, using the `hir` function is needed to prevent the suggestion causing errors when users use bitwise operations; and also this have already existed, for example: `verbose_bit_mask`. Thus, I think this is fine.
changelog: Expands `manual_memcpy` to lint ones with loop counters
bors [Fri, 9 Oct 2020 23:14:58 +0000 (23:14 +0000)]
Auto merge of #6151 - bofh69:master, r=ebroto
Preserve raw strs for: format!(s) to s.to_string() lint
fixes #6142
clippy::useless_format will keep the source's string (after converting {{ and }} to { and }) when suggesting a change from format!() to .to_string() usage. Ie:
| let s = format!(r#""hello {{}}""#);
| ^^^^^^^^^^^^^^^^^^^^^ help: consider using `.to_string()`: `r#""hello {}""#.to_string()`
changelog: [`useless_format`]: preserve raw string literals when no arguments to `format!()` are provided.
projects / rust.git / log