Add lint for `unused_result_ok`
This PR adds a lint to capture the use of `expr.ok();` when the result is not _really_ used.
This could be interpreted as the result being checked (like it is with `unwrap()` or `expect`) but
it actually only ignores the result.
`let _ = expr;` expresses that intent better.
This was also mentionned in #8994 (although not being the main topic of that issue).
changelog: [`misleading_use_of_ok`]: Add new lint to capture `.ok();` when the result is not _really_ used.
lintcheck: force warn all lints
It occurred to me that like `--filter` we could use `--force-warn` for normal operations, we especially want to see lints that crates decided were too annoying or were false positives
Also excludes `clippy::cargo` from the default set as nobody is really writing those and it slows things down
r? `@xFrednet`
changelog: none
Use a deterministic number of digits in rustc_tools_util commit hashes
Using `git rev-parse --short` in rustc_tools_util causes nondeterministic compilation of projects that use `setup_version_info!` and `get_version_info!` when built from the exact same source code and git commit. The number of digits printed by `--short` is sensitive to how many other branches and tags in the repository have been fetched so far, what other commits have been worked on in other branches, how recently you had run `git gc`, platform-specific variation in git's default configuration, and platform differences in the sequence of steps performed by the release pipeline. Someone can compile a tool from a particular commit, switch branches to work on a different commit (or simply do a git fetch), go back to the first commit and be unable to reproduce the binary that was built from it previously.
Currently, variation in short commit hashes causes Clippy version strings to be out of sync between different targets. On x86_64-unknown-linux-gnu:
```console
$ clippy-driver +1.80.0 --version
clippy 0.1.80 (0514789 2024-07-21)
```
Whereas on aarch64-apple-darwin:
```console
$ clippy-driver +1.80.0 --version
clippy 0.1.80 (05147895 2024-07-21)
```
---
changelog: none
Simplify lint deprecation
A couple of small changes:
* A few deprecations were changed to renames. They all had a message similar to "this lint has been replaced by ..." which is just describing a rename.
* The website and warning message are now the same. The website description was usually just a wordier version that contained no extra information. This can be worked around if needed, but I don't think that will happen.
* The legacy deprecations have been removed. rustc should handle this since it already suggests adding the `clippy::` for all lints (deprecated or not) when they're used without it. It wouldn't be a problem to add them back in.
* The website no longer has a "view source" link for deprecated lints since they're no longer read from the HIR tree. I could store the line number, but the link seems totally useless for these lints.
This came up as part of separating the internal lints into their own crate. Both the metadata collector and the lint registration code needs access to the deprecated and renamed lists. This form lets all the deprecations be a separate crate.
r? `@flip1995`
changelog: none
Check exit status of subcommands spawned by rustc_tools_util
The git commands `git rev-parse --short HEAD` and `git log -1 --date=short --pretty=format:%cd` that clippy runs from its build script might fail with **"fatal: not a git repository (or any of the parent directories): .git"** if clippy is being built from a source tarball rather than a git repository. That message is written by git to stderr, and nothing is written to stdout.
For `clippy-driver --version` this PR wouldn't make a difference because it treats empty stdout and failed spawns (`git` is not installed) identically:
7ac242c3d0/rustc_tools_util/src/lib.rs (L35-L42)
But other users of `rustc_tools_util` should be able to expect that the distinction between Some and None is meaningful. They shouldn't need extra code to handle None vs Some-and-empty vs Some-and-nonempty.
---
changelog: none
Remove `multispan_sugg[_with_applicability]`
They're thin wrappers over the corresponding diag method so we should just use that instead
changelog: none
Add clarification for from_iter_instead_of_collect
Close#13147
As mentioned at #13147 we should prefer to use collect depends on situation so clarify this at documentation and provide examples this cases.
changelog: none
Add test for `try_err` lint within try blocks.
Fixes#5757
Turns out the current `try_err` implementation already skips expressions inside of a try block.
When inside of a try block, `Err(_)?` is desugared to a `break` instead of normal `return` . This makes `find_return_type()` function at [this line](eb4d88e690/clippy_lints/src/matches/try_err.rs (L29)) always returns `None` and skips the check.
I just added a test case for try block.
changelog: none
Fix [`redundant_slicing`] when the slice is behind a mutable reference
Fixes#12751
changelog: Fix [`redundant_slicing`] when the slice is behind a mutable reference and a immutable reference is expected.
When a suggestion part is for already present code, do not highlight it. If after that there are no highlights left, do not show the suggestion at all.
Fix clippy lint suggestion incorrectly treated as `span_help`.
Fix `redundant_closure` false positive with closures has return type contains `'static`
Fix#13073 .
Please enable "ignore white-space change" settings in github UI for easy reviewing.
HACK: The third commit contains a hack to check if a type `T: 'static` when `fn() -> U where U: 'static`.
I don't have a clean way to check for it.
changelog: [`redundant_closure`] Fix false positive with closures has return type contains `'static`
Fix false positive for `missing_backticks` in footnote references
Fixes#13183.
changelog: Fix false positive for `missing_backticks` in footnote references
Add possibility to focus on search input using keyboard
This PR adds the possibility to focus on the search input with `S` or `/` like in rustdoc and `mdbook` and `docs.rs` (unification++). Pressing escape will blur it.
r? `@Alexendoo`
changelog: Add possibility to focus on search input using keyboard
Emit `if_let_mutex` in presence of other mutexes
Currently (master, not nightly nor stable) `if_let_mutex` does not emit a warning here:
```rs
let m1 = Mutex::new(10);
let m2 = Mutex::new(());
if let 100..=200 = *m1.lock().unwrap() {
m2.lock();
} else {
m1.lock();
}
```
It currently looks for the first call to `.lock()` on *any* mutex receiver inside of the if/else body, and only later (outside of the visitor) checks that the receiver matches the mutex in the scrutinee. That means that in cases like the above, it finds the `m2.lock()` expression, stops the visitor, fails the check that it's the same mutex (`m2` != `m1`) and then does not look for any other `.lock()` calls.
So, just make the receiver check also part of the visitor so that we only stop the visitor when we also find the right receiver.
The first commit has the actual changes described here. The sceond one just unnests all the `if let`s
----
changelog: none
