Clippy Book Chapter Updates Reborn: Refresh Lint Configuration's looks
This PR modernizes and clears up some confusion with the "Lint Configuration Options" chapter from the book.
### Changes
- **Remove 'Option - Default Value" table**
- Why was it even there?
- It shouldn't be the first thing an user sees when they enter the chapter. It's clunky, ugly and not useful. The default values for configs are stated in a per-config basis if needed.
- **Add a simple description of what the chapter contains, and the scheme of each configuration option**
- **Minor formatting, mainly adding code fragments to code text**
- It seemed weird and jarring not having back-ticks on text like "arithmetic_side_effects".
- Improves readability and separation between configs.
- **Separate a little bit the Affected Lints list + "Affected lists" message**
- Not having something indicating that the list is about the lints that use the configuration option is confusing.
- It isn't as important as the description and example. Therefore should be separated a little bit imo
---
This is an independent effort from #10597, but as it's still a Book Chapter Update, I thought it would be cool to include it here. I'm going to keep the reviewing process for this PR to rustbot's desires.
[Rendered](https://github.com/blyxyas/rust-clippy/blob/book-lint_config/book/src/lint_configuration.md)
[Current](https://github.com/rust-lang/rust-clippy/blob/master/book/src/lint_configuration.md)
changelog: Refresh styling from the "Lint Configuration Options" book chapter.
Update *Current stable* text in `CHANGELOG.md`
Roses are red,
violets are blue,
the new version was released,
and our changelog too
---
changelog: none
add checking for cfg(features = ...)
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: [`maybe_misused_cfg`]: check if `#[cfg(feature = "...")]` misused as `#[cfg(features = "...")]`
I've found that there is no indication when `#[cfg(features = "...")]` is used incorrectly, which can easily make mistakes hard to spot. When I searched for this code on github, I also found many misuse cases([link](https://github.com/search?q=%23%5Bcfg%28features+language%3ARust&type=code)).
PS: This clippy name is just a temporary name, it can be replaced with a better name.
Add spans to `clippy.toml` error messages
Adds spans to errors and warnings encountered when parsing `clippy.toml`.
changelog: Errors and warnings generated when parsing `clippy.toml` now point to the location in the TOML file the error/warning occurred.
Explain which paths clippy searches for configuration in docs
Fixes https://github.com/rust-lang/rust-clippy/issues/9921.
Adds information on where to place the configuration files, it may be a bit verbose. Also added a comment to the section of the code where the search happens, to hopefully prevent changing that without updating the docs.
changelog: Make documentation about where to place configuration files clearer.
new lint: `missing_fields_in_debug`
Fixes#10429
This PR adds a new lint that looks for manual `Debug` implementations that do not "use" all of the fields.
This often happens when adding a new field to a struct.
It also acts as a style lint in case leaving out a field was intentional. In that case, it's preferred to use [`DebugStruct::finish_non_exhaustive`](https://doc.rust-lang.org/stable/std/fmt/struct.DebugStruct.html#method.finish_non_exhaustive), which indicates that there are more fields that were explicitly not shown.
```
changelog: [`missing_fields_in_debug`]: missing fields in manual `Debug` implementation
```
move some strings into consts, more tests
s/missing_field_in_debug/missing_fields_in_debug
dont trigger in macro expansions
make dogfood tests happy
minor cleanups
replace HashSet with FxHashSet
replace match_def_path with match_type
if_chain -> let chains, fix markdown, allow newtype pattern
fmt
consider string literal in `.field()` calls as used
don't intern defined symbol, remove mentions of 'debug_tuple'
special-case PD, account for field access through `Deref`
Remove lint name and category fields from the new lint issue form
changelog: none
Picking a name/category is something the implementers/reviewers tend to cover anyway, I think asking people to come up with it at the time of their suggestion is more of a barrier than it's worth
Inspired by the mention in #10849
[`wildcard_imports`] Modules that contain `prelude` are also allowed
This commit fixes#10846 by checking if the path segment contains the word "prelude", allowing us
`use module_prelude::*`.
changelog: [`wildcard_imports`]: Modules that contain `prelude` are also allowed
`EarlyBinder::new` -> `EarlyBinder::bind`
for consistency with `Binder::bind`. it may make sense to also add `EarlyBinder::dummy` in places where we know that no parameters exist, but I left that out of this PR.
r? `@jackh726` `@kylematsuda`
Uplift `clippy::invalid_utf8_in_unchecked` lint
This PR aims at uplifting the `clippy::invalid_utf8_in_unchecked` lint into two lints.
## `invalid_from_utf8_unchecked`
(deny-by-default)
The `invalid_from_utf8_unchecked` lint checks for calls to `std::str::from_utf8_unchecked` and `std::str::from_utf8_unchecked_mut` with an invalid UTF-8 literal.
### Example
```rust
unsafe {
std::str::from_utf8_unchecked(b"cl\x82ippy");
}
```
### Explanation
Creating such a `str` would result in undefined behavior as per documentation for `std::str::from_utf8_unchecked` and `std::str::from_utf8_unchecked_mut`.
## `invalid_from_utf8`
(warn-by-default)
The `invalid_from_utf8` lint checks for calls to `std::str::from_utf8` and `std::str::from_utf8_mut` with an invalid UTF-8 literal.
### Example
```rust
std::str::from_utf8(b"ru\x82st");
```
### Explanation
Trying to create such a `str` would always return an error as per documentation for `std::str::from_utf8` and `std::str::from_utf8_mut`.
-----
Mostly followed the instructions for uplifting a clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
````@rustbot```` label: +I-lang-nominated
r? compiler
-----
For Clippy:
changelog: Moves: Uplifted `clippy::invalid_utf8_in_unchecked` into rustc
deps: drop serde feature from url, drop rustc-workspace-hack
Cargo now have it's own workspace and rustc dropped [`rustc-workspace-hack`](https://github.com/rust-lang/rust/pull/109133), so no need to unify features here; drop rustc-workspace-hack.
changelog: none
Changelog for Rust 1.70 🔨
Roses are red,
violets are blue,
damn I have an exam to cram,
and this rhyme is a scam
---
This poem is... certainly something... Anyways, hope whoever is reading this, has a lovely day full of sunshine without the need to study :D
---
changelog: none
Each of `{D,Subd}iagnosticMessage::{Str,Eager}` has a comment:
```
// FIXME(davidtwco): can a `Cow<'static, str>` be used here?
```
This commit answers that question in the affirmative. It's not the most
compelling change ever, but it might be worth merging.
This requires changing the `impl<'a> From<&'a str>` impls to `impl
From<&'static str>`, which involves a bunch of knock-on changes that
require/result in call sites being a little more precise about exactly
what kind of string they use to create errors, and not just `&str`. This
will result in fewer unnecessary allocations, though this will not have
any notable perf effects given that these are error paths.
Note that I was lazy within Clippy, using `to_string` in a few places to
preserve the existing string imprecision. I could have used `impl
Into<{D,Subd}iagnosticMessage>` in various places as is done in the
compiler, but that would have required changes to *many* call sites
(mostly changing `&format("...")` to `format!("...")`) which didn't seem
worthwhile.
Fixing `invalid_regex` with invalid UTF8. Also, adding more test cases
Fixing false positive and false negative when dealing with regex that could match invalid UTF8.
This PR fixes https://github.com/rust-lang/rust-clippy/issues/10825
changelog: [`invalid_regex`]: Fixing false positive and false negative when dealing with regex that could match invalid UTF8
Improve pattern printing for manual_let_else
* Address a formatting issue pointed out in https://github.com/rust-lang/rust-clippy/pull/10175/files#r1137091002
* Replace variables inside | patterns in the if let: `let v = if let V::A(v) | V::B(v) = v { v } else ...`
* Support nested patterns: `let v = if let Ok(Ok(Ok(v))) = v { v } else ...`
* Support tuple structs with more than one arg: `let v = V::W(v, _) = v { v } else ...`; note that more than one *capture* is still not supported, so it bails for `let (v, w) = if let E::F(vi, wi) = x { (vi, wi)}`
* Correctly handle .. in tuple struct patterns: `let v = V::X(v, ..) = v { v } else ...`
- \[ ] Followed [lint naming conventions][lint_naming]
- \[x] Added passing UI tests (including committed `.stderr` file)
- \[x] `cargo test` passes locally
- \[ ] Executed `cargo dev update_lints`
- \[ ] Added lint documentation
- \[x] Run `cargo dev fmt`
[lint_naming]: https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints
---
changelog: [`manual_let_else`]: improve variable name in suggestions
Closes#10431 as this PR is adding a test for the `mut` case.
Ignore `#[cfg]`'d out code in `needless_else`
changelog: none (same release as #10810)
`#[cfg]` making things fun once more
This lead me to think about macro calls that expand to nothing as well, but apparently they produce an empty stmt in the AST so are already handled, added a test for that
r? `@llogiq`
[`default_constructed_unit_structs`]: do not lint on type alias paths
Fixes#10755.
Type aliases cannot be used as a constructor, so this lint should not trigger in those cases.
I also changed `clippy_utils::is_ty_alias` to also consider associated types since [they kinda are type aliases too](48ec50ae39/compiler/rustc_resolve/src/late/diagnostics.rs (L1520)).
changelog: [`default_constructed_unit_structs`]: do not lint on type alias paths
[`unused_async`]: do not consider `await` in nested `async` blocks as used
Fixes#10800.
This PR makes sure that `await` expressions inside of inner `async` blocks don't prevent the lint from triggering.
For example
```rs
async fn foo() {
async {
std::future::ready(()).await;
}
}
```
Even though there *is* a `.await` expression in this function, it's contained in an async block, which means that the enclosing function doesn't need to be `async` too.
changelog: [`unused_async`]: do not consider `await` in nested `async` blocks as used
