Refactor `absolute_paths`
Checks are rearranged to do the more expensive checks later. Since the most likely path length will be one (locals and imported/local items) this will exclude such paths on the first check.
Tests were rewritten as they were hard to follow (annotations would have helped), spammy (lots of tests for the same thing) and insufficient.
One thing thing that came up and should be decided on now is what to do about the difference between `path::to::Trait::item` (4 segments) and `path::to::Type::item` (3 segments). The current behaviour treats these as different lengths which is terrible. I personally think these should both be three segments since the item can't actually be imported. Only the type or the trait could be. This makes `crate_name::Trait::item` the shortest absolute path which is shorter than the lint allows by default.
changelog: None
Respect allow `inconsistent_struct_constructor` on the struct definition
Closes#13203
Now we check if the target type is marked with `#[allow(clippy:inconsistent_struct_constructor)]` before lining.
As a side-effect of this change, The rule in the subject no longer runs on non-local `AdtDef`s. However, as suggested by `@Jarcho` it shouldn't be a big deal since most of the time we didn't have access to this information anyway.
> You can't get lint attributes from other crates. I would probably just restrict the lint to only work with types from the current crate while you're at it. Upstream crates don't have a definition order from the point of view of the current crate (with the exception of #[repr(C)] structs).
changelog: Respect allow `inconsistent_struct_constructor` on the struct definition.
Miscellaneous improvements to struct tail normalization
1. Make checks for foreign tails more accurate by normalizing the struct tail. I didn't write a test for this one.
2. Normalize when computing struct tail for `offset_of` for slice/str. This fixes the new solver only.
3. Normalizing when computing tails for disaligned reference check. This fixes both solvers.
r? lcnr
By splitting the `FnSig` within `TyKind::FnPtr` into `FnSigTys` and
`FnHeader`, which can be packed more efficiently. This reduces the size
of the hot `TyKind` type from 32 bytes to 24 bytes on 64-bit platforms.
This reduces peak memory usage by a few percent on some benchmarks. It
also reduces cache misses and page faults similarly, though this doesn't
translate to clear cycles or wall-time improvements on CI.
Don't use `LateContext` in the constant evaluator
This also changes the interface to require explicitly creating the context. `constant` could be added back in, but the others are probably not worth it.
A couple of bugs have been fixed. The wrong `TypeckResults` was used once when evaluating a constant, and the wrong `ParamEnv` was used by some callers (there wasn't a way to use the correct one).
changelog: none
`single_match`: fix checking of explicitly matched enums
fixes#11365
This approach has false-negatives, but fixing them will require a significant amount of additional state tracking. The comment in `add_and_pats` has the explanation.
changelog: `single_match`: correct checking if the match explicitly matches all of an enum's variants.
Add path prefixes back when compiling `clippy_dev` and `lintcheck`
`cargo dev` and `cargo lintcheck` use `--manifest-path` to select the package to compile, with this Cargo changes the CWD to the package's containing directory meaning paths in diagnostics start from e.g. `src/` instead of `clippy_dev/src/`
Lintcheck uses a `--remap-path-prefix` trick when linting crates to re-add the directory name in diagnostics:
5ead90f13a/lintcheck/src/main.rs (L93-L94)5ead90f13a/lintcheck/src/main.rs (L102-L103)
It works well as far as I can tell, when absolute paths appear they stay absolute and do not have the prefix added
[`profile-rustflags`](https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#profile-rustflags-option) allows us to set per package `RUSTFLAGS` in order to use the same trick on the `clippy_dev` and `lintcheck` packages themselves
Now when you run into warnings/errors the filename will be correctly clickable
Before
```
error[E0425]: cannot find value `moo` in this scope
--> src/lib.rs:41:5
|
41 | moo;
| ^^^ not found in this scope
```
After
```
error[E0425]: cannot find value `moo` in this scope
--> clippy_dev/src/lib.rs:41:5
|
41 | moo;
| ^^^ not found in this scope
```
r? `@flip1995`
changelog: none
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
