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
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.
Renamed the good first issue label in CONTRIBUTING.md
Follow up from #6468
Grep found some more references to the old `good first issue`.
[CONTRIBUTING.md rendered](https://github.com/xFrednet/rust-clippy/blob/0000-rename-good-first-issue-in-docs/CONTRIBUTING.md)
<details>
<summary>grep output</summary>
```
$ 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:896d82f7ff64644656bda7a4ed8bbd55ca3b7619 1f58c2bb8a xFrednet <xFrednet@gmail.com> 1608326295 +0000 commit: Renamed the good first issue label for rustbot
rust-clippy/.git/logs/HEAD:9be704584f05e5a6c3ba2708590f98c1f261d19a ced54f2867 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:896d82f7ff64644656bda7a4ed8bbd55ca3b7619 1f58c2bb8a 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:9be704584f05e5a6c3ba2708590f98c1f261d19a ced54f2867 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>
---
changelog: None
r? `@flip1995`
needless_doctest_main: handle correctly parse errors
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.
changelog: needless_doctest_main: handle correctly parse errors
Fixes#6022
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.
changelog: none
This should hopefully fix incremental compilation ICEs from rustc that I have been encountering multiple times while working with the previous nightly.
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
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.
changelog: none
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` 😄)
Fixes#5214 and avoids frustration for users unfamiliar with the issue
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.
cc #5394
changelog: none
📌 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.
* ???
`@rust-lang/clippy` thoughts?
r? `@flip1995`
