Matthias Krüger [Tue, 22 Dec 2020 00:24:59 +0000 (01:24 +0100)]
readme: remove paragraph about executing clippy via "cargo run .."
This most likely no longer works since we are pinning clippy on a specific nightly now.
"cargo run" would try to compile clippy with whatever version the project we want to check demands.
Also building clippy yourself to run it on a project is not really needed anymore since clippy is shipped with official rust releases.
bors [Sat, 19 Dec 2020 22:01:45 +0000 (22:01 +0000)]
Auto merge of #6477 - xFrednet:0000-enable-search-with-dashes, r=ebroto
Adapted the website search for better matching
* This adds the ability to search for ids with dashes and spaces in the name.
* Example: `missing-errors-doc` and `missing errors doc` are now valid aliases for lint names
* It also improves the fuzzy search in the description. This search will now match any lint that where all searched words are inside the description.
* Example: `doc section` finds two lints in our selection
This was suggested/discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Enable.20lint.20search.20with.20dashes/near/220469464)
### Testing
These changes can be tested locally by:
1. Clone this branch
2. Download the current lint index from the [gh-pages branch](https://github.com/rust-lang/rust-clippy/blob/gh-pages/master/lints.json)
3. Put it next to the `util/gh-pages/index.html` and open the html file. Make sure that it can load the lint data. (Browsers can be a bit iffy when opening a loacl html page and loading data)
### Note
I found that searching only a few characters (< 3) seams slow and deleting one even more as almost every lint description contains them. This also happens in our current [lint list](https://rust-lang.github.io/rust-clippy/master/index.html). We could change the search to only be triggered if the search field contains more than 3 letters to slightly improve performance.
---
changelog: Adapted the website search for better matching
bors [Sat, 19 Dec 2020 21:39:19 +0000 (21:39 +0000)]
Auto merge of #6316 - ThibsG:WrongSelfConventionTraitDef, r=ebroto
Lint also in trait def for `wrong_self_convention`
Extends `wrong_self_convention` to lint also in trait definition.
By the way, I think the `wrong_pub_self_convention` [example](https://github.com/rust-lang/rust-clippy/blob/dd826b4626c00da53f76f00f02f03556803e9cdb/clippy_lints/src/methods/mod.rs#L197) is misleading.
On [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=32615ab3f6009e7e42cc3754be0ca17f), it fires `wrong_self_convention`, so the example (or the lint maybe?) needs to be reworked.
The difference with `wrong_self_convention` [example](https://github.com/rust-lang/rust-clippy/blob/dd826b4626c00da53f76f00f02f03556803e9cdb/clippy_lints/src/methods/mod.rs#L172) is mainly the `pub` keyword on the method `as_str`, but the lint doesn't use the function visibility as condition to choose which lint to fire (in fact it uses the visibility of the impl item).
fixes: #6307
changelog: Lint `wrong_self_convention` lint in trait def also
bors [Sat, 19 Dec 2020 12:28:00 +0000 (12:28 +0000)]
Auto merge of #6471 - phansch:fix-bless, r=flip1995
Fix blessing of new reference files
Adding of new reference files wasn't handled correctly. It was trying to
read a file that didn't exist yet.
Instead of unwrapping, we now treat a missing reference file as empty
(`Vec::new`). This makes the following conditional work. We then also
have to re-read the reference file after it was being copied. This
second read is technically the same as in the old shell script, but
wasn't really obvious there. The shell script did a `-s` test which
reads the file as well.
changelog: internal: Fix `cargo dev bless` when new reference files are added
Philipp Hansch [Sat, 19 Dec 2020 07:25:42 +0000 (08:25 +0100)]
Fix blessing of new reference files
Adding of new reference files wasn't handled correctly. It was trying to
read a file that didn't exist yet.
Instead of unwrapping, we now treat a missing reference file as empty
(`Vec::new`). This makes the following conditional work. We then also
have to re-read the reference file after it was being copied. This
second read is technically the same as in the old shell script, but
wasn't really obvious. The shell script did a `-s` test which reads the
file.
```
$ grep -Ri "good first issue" rust-clippy/
rust-clippy/.git/COMMIT_EDITMSG:Renamed the good first issue label in CONTRIBUTING.md
rust-clippy/.git/logs/HEAD:896d82f7ff64644656bda7a4ed8bbd55ca3b76191f58c2bb8a638a63edc1f3503c8771937aa19157 xFrednet <xFrednet@gmail.com> 1608326295 +0000 commit: Renamed the good first issue label for rustbot
rust-clippy/.git/logs/HEAD:9be704584f05e5a6c3ba2708590f98c1f261d19aced54f28671ddb9ccf9b44131d522f4fdeab7097 xFrednet <xFrednet@gmail.com> 1608329602 +0000 commit: Renamed the good first issue label in CONTRIBUTING.md
rust-clippy/.git/logs/refs/heads/0000-rename-good-first-issue-in-docs:896d82f7ff64644656bda7a4ed8bbd55ca3b76191f58c2bb8a638a63edc1f3503c8771937aa19157 xFrednet <xFrednet@gmail.com> 1608326295 +0000 commit: Renamed the good first issue label for rustbot
rust-clippy/.git/logs/refs/heads/0000-rename-good-first-issue-in-docs:9be704584f05e5a6c3ba2708590f98c1f261d19aced54f28671ddb9ccf9b44131d522f4fdeab7097 xFrednet <xFrednet@gmail.com> 1608329602 +0000 commit: Renamed the good first issue label in CONTRIBUTING.md
rust-clippy/CONTRIBUTING.md:Some issues are easier than others. The [`good first issue`] label can be used to find the easy issues.
rust-clippy/CONTRIBUTING.md:[`E-medium`] issues are generally pretty easy too, though it's recommended you work on an [`good first issue`]
rust-clippy/CONTRIBUTING.md:[`good first issue`]: https://github.com/rust-lang/rust-clippy/labels/good%20first%20issue
```
</details>
bors [Fri, 18 Dec 2020 21:25:39 +0000 (21:25 +0000)]
Auto merge of #6468 - xFrednet:0000-rename-good-first-issue-for-rustbot, r=flip1995
Renamed the good first issue label for rustbot
The `good first issue` label got renamed to `good-first-issue`. See [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Rename.20the.20.22good.20first.20issue.22.20label.20for.20bot.20usage/near/220428379) to enable the assignment with rustbot.
xFrednet [Fri, 18 Dec 2020 21:18:15 +0000 (21:18 +0000)]
Renamed the good first issue label for rustbot
See https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Rename.20the.20.22good.20first.20issue.22.20label.20for.20bot.20usage/near/220428018
Before this change, finding an error when parsing a doctest would make Clippy exit without emitting an error. Now we properly catch a fatal error and ignore it.
Also, if a doctest specifies an edition in the info line, it will be used when parsing it.
I probably should do a few more things before this can be merged:
- [x] Add tests (added basic tests, more advanced tests could be done in the future?)
- [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements)
- [x] Fix clippy
However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs.
Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this?
r? `@ghost` for now
bors [Tue, 15 Dec 2020 22:00:02 +0000 (22:00 +0000)]
Auto merge of #78399 - vn-ki:gsgdt-graphviz, r=oli-obk
make MIR graphviz generation use gsgdt
gsgdt [https://crates.io/crates/gsgdt] is a crate which provides an
interface for stringly typed graphs. It also provides generation of
graphviz dot format from said graph.
This is the first in a series of PRs on moving graphviz code out of rustc into normal crates and then implementating graph diffing on top of these crates.
I removed code from the `Inline` MIR pass that forcibly disabled
inlining if `-Zinstrument-coverage` was set. The default `mir_opt_level`
does not enable inlining anyway. But if the level is explicitly set and
is greater than 1, I issue a warning.
The new warnings show up in tests, which is much better for diagnosing
potential option conflicts in these cases.
bors [Mon, 14 Dec 2020 17:23:51 +0000 (17:23 +0000)]
Auto merge of #6452 - matthiaskrgr:bump_nightly, r=flip1995
bump pinned nightly from nightly-2020-12-09 to nightly-2020-12-14
This should hopefully fix incremental compilation ICEs in rustc that I have encountered multiple times while working with the previously pinned nightly.
Matthias Krüger [Mon, 14 Dec 2020 16:47:05 +0000 (17:47 +0100)]
bump pinned nightly from nightly-2020-12-09 to nightly-2020-12-14
This should hopefully fix incremental compilation ICEs from rustc that I have been encountering multiple times while working with the previous nightly.
bors [Sun, 13 Dec 2020 21:28:38 +0000 (21:28 +0000)]
Auto merge of #6435 - xFrednet:5552-false-positive-match-single-binding, r=ebroto
Fixing a false positive for the `match_single_binding` lint #5552
This is a fix for a false positive in the `match_single_binding` lint when using `#[cfg()]` on a branch. It is sadly a bit hacky but maybe the best solution as rust removes the other branch from the AST before we can even validate it. This fix looks at the code snippet itself and returns if it includes another thick arrow `=>` besides the one matching arm we found. This can again cause false negatives if someone has the following code:
```rust
match x {
// => <-- Causes a false negative
_ => 1,
}
```
I thought about making the code more complex and maybe validating against other things like the `#[cfg()]` macro but I believe that this is the best solution. This has basically switched the issue from a false positive to a false negative in a very specific case.
I'm happy to make some changes if you have any suggestions 🙃.
---
Fixes #5552
changelog: Fixed a false positive in the `match_single_binding` lint with `#[cfg()]` macro
bors [Sun, 13 Dec 2020 18:07:57 +0000 (18:07 +0000)]
Auto merge of #6450 - matthiaskrgr:dont_format_local_repo, r=ebroto
cargo dev fmt: don't format entire rustc repo if we ran ra_setup previously
It turns out that rustfmt sees a rustc repo that we pulled in as path dependency via `cargo dev ra-setup` as part of the tree and would try to format it :D
Of course we don't want this, so skip formatting if we see that we ran `ra-setup` previously.
bors [Sun, 13 Dec 2020 16:37:31 +0000 (16:37 +0000)]
Auto merge of #6441 - ebroto:use_rustflags, r=flip1995
Pass Clippy args also trough RUSTFLAGS
This removes a hack (\_\_CLIPPY_HACKERY\_\_) to add another one :)
It allows this workflow to work:
```terminal
cargo clippy # warning: empty `loop {}` wastes CPU cycles
cargo clippy -- -A clippy::empty_loop # no warnings emitted
```
Before this change the new flag was not taken into consideration in cargo's fingerprint and the warning was emitted again. I guess that ideally we could add a specific env var for compiler wrapper arguments, but in the meantime this should do the job.
changelog: Pass clippy arguments through RUSTFLAGS so that changing them will trigger a rebuild
r? `@flip1995`
cc `@ehuss` (I think this may count as another step towards stabilizing `RUSTC_WORKSPACE_WRAPPER` :smile:)
Fixes #5214 and avoids frustration for users unfamiliar with the issue
bors [Sat, 12 Dec 2020 14:42:28 +0000 (14:42 +0000)]
Auto merge of #6413 - phansch:bless, r=flip1995
Rewrite update-all-references bash scripts in Rust
This replaces the `update-all-references` scripts with a single
cargo dev bless
command. It should behave mostly the same as the bash scripts. The major difference is, that it can be called from the project root and will always update the files in all of the test suites.
bors [Fri, 11 Dec 2020 16:25:13 +0000 (16:25 +0000)]
Auto merge of #6401 - ebroto:pin_to_a_nightly, r=ebroto
📌 Pin Clippy to a nightly 📌
changelog: Pin Clippy to a specific nightly version (No more master/custom toolchain required to compile Clippy)
Addresses partially #5561. As proposed there in [this comment](https://github.com/rust-lang/rust-clippy/issues/5561#issuecomment-623109095), this kicks off the process, to help us get acquainted with how the syncs should work, before working on improving the tooling.
Open questions:
* When performing a rustup, we will need to exclude the commits that were merged that same day, or else wait until that nightly is released. I did not update the documentation about this part, mainly because I'm not sure about how to do that.
* When should we perform the rustups now? My first idea is to do it at the same time we do the clippyups, to have a clear cadence and to avoid the two copies of the repo to diverge enough to make the process painful.
* Who does the rustups now? If we follow my previous idea and do both rustup and clippyup at the same time, it would be more work for `@flip1995` who currently does the clippyups. I would prefer to establish some kind of rotation to spead the work. Other ideas?
* I'm not sure if this affects the release process in any way.
* ???
bors [Fri, 11 Dec 2020 08:38:19 +0000 (08:38 +0000)]
Auto merge of #6424 - Suyash458:master, r=flip1995
Add MSRV to more lints specified in #6097
add MSRV to more lints specified in #6097
add instructions for adding msrv in other lints
update tests
- [x] `redundant_field_names` requires Rust 1.17 due to suggest feature stablized in that version.
- [x] `redundant_static_lifetimes` requires Rust 1.17 due to suggest feature stablized in that version.
- [x] `filter_map_next` requires Rust 1.30 due to suggest `Iterator::find_map`.
- [x] `checked_conversions` requires Rust 1.34 due to suggest `TryFrom`.
- [x] `match_like_matches_macro` requires Rust 1.42 due to suggest `matches!`. Addressed in #6201
- [x] `manual_strip` requires Rust 1.45 due to suggest `str::{strip_prefix, strip_suffix}`. Addressed in #6201
- [x] `option_as_ref_deref` requires Rust 1.40 due to suggest `Option::{as_deref, as_deref_mut}`. Addressed in #6201
- [x] `manual_non_exhaustive` requires Rust 1.40 due to suggest `#[non_exhaustive]`. Addressed in #6201
- [x] `manual_range_contains` requires Rust 1.35 due to suggest `Range*::contains`.
- [x] `use_self` requires Rust 1.37 due to suggest `Self::Variant on enum`.
- [x] `mem_replace_with_default` requires Rust 1.40 due to suggest `mem::take`.
- [x] `map_unwrap_or` requires Rust 1.41 due to suggest `Result::{map_or, map_or_else}`.
- [x] `missing_const_for_fn` requires Rust 1.46 due to `match/if/loop in const fn` needs that version.
changelog: Add MSRV config to more lints. ^This is now the complete list, AFAWK
flip1995 [Thu, 10 Dec 2020 08:36:19 +0000 (09:36 +0100)]
Stop caching on CI
The only thing we now cache is cargo-cache, which we only use for cache.
That's a catch-22 if I ever seen one. And for Clippy itself we always
want to do a clean build and not cache anything.
bors [Wed, 9 Dec 2020 17:08:00 +0000 (17:08 +0000)]
Auto merge of #6218 - korrat:master, r=ebroto
Add lint for maps with zero-sized value types
Hi, this is my first time contributing to clippy or rust in general, so I'm not sure about the details of contributing. Please excuse me and let me now if I did anything wrong. I have a couple of questions:
1. I'm not sure what category this lint should be. I've put it in "nursery" for now.
1. Should I squash commits this is reviewed/merged?
changelog: Add lint for maps with zero-sized value types
bors [Wed, 9 Dec 2020 15:37:20 +0000 (15:37 +0000)]
Auto merge of #6188 - ebroto:primary_package, r=flip1995
Add --no-deps option to avoid running on path dependencies in workspaces
Since rust-lang/cargo#8758 has hit nightly, this allows us to address the second bullet point and [the concern related to `--fix`](https://github.com/rust-lang/cargo/issues/8143#issuecomment-619289546) in the [RUSTC_WORKSPACE_WRAPPER tracking issue](https://github.com/rust-lang/cargo/issues/8143).
As a reminder stabilizing that env var will solve #4612 (Clippy not running after `cargo check` in stable) and would allow to stabilize the `--fix` option in Clippy.
changelog: Add `--no-deps` option to avoid running on path dependencies in workspaces