Fix `empty_line_after_outer_attribute` false positive
This PR fixes a false positive in `empty_line_after_outer_attribute`.
Here is a minimal example that trigger the FP:
```rust
#[derive(clap::Parser)]
#[clap(after_help = "This ia a help message.
You're welcome.
")]
pub struct Args;
```
changelog: PF: [`empty_line_after_outer_attribute`]: No longer lints empty lines in inner string values.
Introduce `allow-dbg-in-tests` config value
related to: Issue #8758, PR https://github.com/rust-lang/rust-clippy/pull/8838
changelog: Introduced `allow-dbg-in-tests` config value. [dbg_macro] does not allow `dbg!` in test code by default.
`get_last_with_len`: lint `VecDeque` and any deref to slice
changelog: [`get_last_with_len`]: lint `VecDeque` and any deref to slice
Previously only `Vec`s were linted, this will now catch any usages on slices, arrays, etc. It also suggests `.back()` for `VecDeque`s
Also moves the lint into `methods/`
`identity_op`: add parenthesis to suggestions where required
changelog: [`identity_op`]: add parenthesis to suggestions where required
Follow up to #8730, wraps the cases we can't lint as-is in parenthesis rather than ignoring them
Catches a couple new FPs with mixed operator precedences and `as` casts
```rust
// such as
0 + { a } * 2;
0 + a as usize;
```
The suggestions are now applied using `span_lint_and_sugg` rather than appearing in just the message and have a `run-rustfix` test
Rustup
`@rust-lang/clippy,` `@Jarcho,` `@dswij,` `@Alexendoo.` Could someone review this? It should be pretty straight forward since it's just a sync. I think it's also fine if either one of `@Jarcho,` `@dswij,` `@Alexendoo` approves this, as these are usually not reviewed. I just want to make sure that I didn't break something obvious 🙃
It should be enough to look at the merge commit 🙃
changelog: none
changelog: move [`significant_drop_in_scrutinee`] to `suspicious`
[dbg_macro] tolerates use of `dbg!` in items which have `#[cfg(test)]` attribute
fix: #8758
changelog: [dbg_macro] tolerates use of `dbg!` in items with `#[cfg(test)]` attribute
Improve "unknown field" error messages
Fixes#8806
Sample output:
```
error: error reading Clippy's configuration file `/home/smoelius/github/smoelius/rust-clippy/clippy.toml`: unknown field `foobar`, expected one of
allow-expect-in-tests enable-raw-pointer-heuristic-for-send standard-macro-braces
allow-unwrap-in-tests enforced-import-renames third-party
allowed-scripts enum-variant-name-threshold too-large-for-stack
array-size-threshold enum-variant-size-threshold too-many-arguments-threshold
avoid-breaking-exported-api literal-representation-threshold too-many-lines-threshold
await-holding-invalid-types max-fn-params-bools trivial-copy-size-limit
blacklisted-names max-include-file-size type-complexity-threshold
cargo-ignore-publish max-struct-bools unreadable-literal-lint-fractions
cognitive-complexity-threshold max-suggested-slice-pattern-length upper-case-acronyms-aggressive
cyclomatic-complexity-threshold max-trait-bounds vec-box-size-threshold
disallowed-methods msrv verbose-bit-mask-threshold
disallowed-types pass-by-value-size-limit warn-on-all-wildcard-imports
doc-valid-idents single-char-binding-names-threshold
at line 1 column 1
```
You can test this by (say) adding `foobar = 42` to Clippy's root `clippy.toml` file, and running `cargo run --bin cargo-clippy`.
Note that, to get the terminal width, this PR adds `termize` as a dependency to `cargo-clippy`. However, `termize` is also [how `rustc_errors` gets the terminal width](481db40311/compiler/rustc_errors/src/emitter.rs (L1607)). So, hopefully, this is not a dealbreaker.
r? `@xFrednet`
changelog: Enhancements: the "unknown field" error messages for config files now wraps the field names.
add suggestions to rc_clone_in_vec_init
A followup to https://github.com/rust-lang/rust-clippy/pull/8769
I also switch the order of the 2 suggestions, since the loop initialization one is probably the common case.
`@xFrednet` I'm not letting you guys rest for a minute 😅
changelog: add suggestions to [`rc_clone_in_vec_init`]
`undocumented_unsafe_blocks` does not trigger on unsafe trait impls
Closes#8505
changelog: This lint checks unsafe impls NOT from macro expansions and checks ones in macro declarations.
~~`unsafe impl`s from macro invocations don't trigger the lint for now.~~
~~This lint checks unsafe impls from/not from macro expansions~~
Don't lint `vec_init_then_push` when further extended
fixes#7071
This will still lint when a larger number of pushes are done (four currently). The exact number could be debated, but this is more readable then a sequence of pushes so it shouldn't be too large.
changelog: Don't lint `vec_init_then_push` when further extended.
changelog: Remove `mut` binding from `vec_init_then_push` when possible.
Add EarlyBinder
Chalk has no concept of `Param` (e0ade19d13/chalk-ir/src/lib.rs (L579)) or `ReEarlyBound` (e0ade19d13/chalk-ir/src/lib.rs (L1308)). Everything is just "bound" - the equivalent of rustc's late-bound. It's not completely clear yet whether to move everything to the same time of binder in rustc or add `Param` and `ReEarlyBound` in Chalk.
Either way, tracking when we have or haven't already substituted out these in rustc can be helpful.
As a first step, I'm just adding a `EarlyBinder` newtype that is required to call `subst`. I also add a couple "transparent" `bound_*` wrappers around a couple query that are often immediately substituted.
r? `@nikomatsakis`
Fix redundant_allocation warning for Rc<Box<str>>
changelog: [`redundant_allocation`] Fixes#8604
Fixes false positives where a fat pointer with `str` type was made thin by another allocation, but that thinning allocation was marked as redundant
