Use depinfo to discover UI test dependencies
changelog: none
context: https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Building.20test.20dependencies
This restores [the old `EXTERN_FLAGS` method](4cf5bdc60c/tests/compile-test.rs (L67-L75)) of passing `--extern` flags for building UI tests with minor changes
- Unused deps were removed
- It's now a `Vec` of args instead of a command string
- It uses a `BTreeMap` so the extern flags are in alphabetical order and deterministic
I don't know if the `HOST_LIBS` part is still required, but I figured it best to leave it in for now. If the change is accepted we can take a look if it's needed in `rust-lang/rust` after the next sync
This isn't as pleasant as having a `Cargo.toml`, though there is something satisfying about knowing the dependencies are already built and not needing to invoke `cargo`
r? `@flip1995`
[`filter_next`]: suggest making binding mutable if it needs to be
Fixes#10029
changelog: [`filter_next`]: suggest making binding mutable if it needs to be and adjust applicability
[`unnecessary_literal_unwrap`]: don't lint if binding initializer comes from expansion
Fixes https://github.com/rust-lang/rust-clippy/discussions/11109
changelog: [`unnecessary_literal_unwrap`]: don't lint if binding initializer comes from expansion
"try this" -> "try"
Current help messages contain a mix of "try", "try this", and one "try this instead". In the spirit of #10631, this PR adopts the first, as it is the most concise.
It also updates the `lint_message_conventions` test to catch cases of "try this".
(Aside: #10120 unfairly contained multiple changes in one PR. I am trying to break that PR up into smaller pieces.)
changelog: Make help messages more concise ("try this" -> "try").
Add `needless_pass_by_ref_mut` lint
changelog: [`needless_pass_by_ref_mut`]: This PR add a new lint `needless_pass_by_ref_mut` which emits a warning in case a `&mut` function argument isn't used mutably. It doesn't warn on trait and trait impls functions.
Fixes#8863.
New lint [`manual_partial_ord_and_ord_impl`]
Lints when both `PartialOrd` and `Ord` are manually implemented yet the body of `PartialOrd::partial_cmp` isn't `Some(self.cmp(<other>))`.
This is in `correctness` currently but I'm ok with elsewhere.
Closes#10744
---
changelog: new lint [`needless_partial_ord_impl`]
[#10788](https://github.com/rust-lang/rust-clippy/pull/10788)
cargo dev fmt
cargo test passes
cargo test passes
refactor a lil
Update bool_comparison.stderr
heavily refactor + bump `clippy::version`
refactor
refactor
check bounds to increase accuracy, and add todos
Fix changelog PR listings, create them automatically in `fetch_prs_between.sh`
changelog: none
`fetch_prs_between.sh` now finds the date of the newest and oldest merges from GitHub to use in the range, this does add a dependency on https://github.com/cli/cli
It also no longer prints rollups/merges that come from rustc, so only clippy changes should be printed
r? `@xFrednet`
cc #10847
Pass correct substs to `implements_trait` in `incorrect_impls`
`Copy<T>` does in fact not exist. The substs on the trait_ref contain the `Self` type of the impl as the first parameter, so passing that to `implements_trait`, which then nicely prepends the `Self` type for us does not end will.
fixes #11121
The assertions requires debug assertions inside rustc, which is probably why it didn't fire here. I tested the change locally in rust-lang/rust and it did not ICE anymore.
cc `@xFrednet` `@Centri3`
changelog: [`incorrect_impls`]: fix confusion about generic parameters
`Copy<T>` does in fact not exist. The substs on the trait_ref contain
the `Self` type of the impl as the first parameter, so passing that
to `implements_trait`, which then nicely prepends the `Self` type
for us does not end will.
Fix regex lints for regex 1.9.0
regex 1.9.0 was [just released](https://blog.burntsushi.net/regex-internals/), which changes where the types are defined. Instead of updating the definitions to the ones in 1.9.0 this PR uses [`def_path_def_ids`](https://doc.rust-lang.org/nightly/nightly-rustc/clippy_utils/fn.def_path_def_ids.html) on the canonical paths so that we don't have to worry about third party crate internals
This means that it still works with older regex versions too, and will for any future layout changes. I tested it with 1.8.4 and 1.9.0
changelog: [`INVALID_REGEX`], [`TRIVIAL_REGEX`]: now works with regex 1.9.0
new lint: `read_line_without_trim`
This adds a new lint that checks for calls to `Stdin::read_line` with a reference to a string that is then attempted to parse into an integer type without first trimming it, which is always going to fail at runtime.
This is something that I've seen happen a lot to beginners, because it's easy to run into when following the example of chapter 2 in the book where it shows how to program a guessing game.
It would be nice if we could point beginners to clippy and tell them "let's see what clippy has to say" and have clippy explain to them why it fails 👀
I think this lint can later be "generalized" to work not just for `Stdin` but also any `BufRead` (which seems to be where the guarantee about the trailing newline comes from) and also, matching/comparing it to a string slice that doesn't end in a newline character (e.g. `input == "foo"` is always going to fail)
changelog: new lint: [`read_line_without_trim`]
[`useless_vec`]: add more tests and don't lint inside of macros
Closes#11084.
I realized that the fix I added in #11081 itself also causes an error in a suggestion when inside of a macro. Example:
```rs
macro_rules! x {
() => {
for _ in vec![1, 2] {}
}
}
x!();
```
Here it would suggest replacing `vec![1, 2]` with `[x!()]`, because that's what the source callsite is (reminder: it does this to get the correct span of `x!()` for code like `for _ in vec![x!()]`), but that's wrong when *inside* macros, so I decided to make it not lint if the whole loop construct is inside a macro to avoid this issue.
changelog: [`useless_vec`]: add more tests and don't lint inside of macros
r? `@Alexendoo` since these were your tests, I figured it makes most sense to assign you
Don't lint manual_let_else in cases where ? would work
Don't lint `manual_let_else` where the question mark operator `?` would be sufficient, that is, mostly in cases like:
```Rust
let v = if let Some(v) = ex { v } else { return None };
```
Also, this PR emits the `question_mark` lint for `let...else` patterns that could be written with `?` (also, only `return None` like cases).
```
changelog: [`manual_let_else`]: don't lint in cases where question_mark already lints
changelog: [`question_mark`]: lint for `let Some(...) = ex else { return None };`
```
Fixes #8755
[`useless_vec`]: use the source span for initializer
Fixes#11075.
changelog: [`useless_vec`]: use the source span for the initializer expression when inside of a macro
