Add a test for ice-3717.rs
this PR is a part of https://github.com/rust-lang/rust-clippy/issues/13099.
Based on the changes introduced in #13098 for introduce ui_test, we will update the uitest output.
This is a fix for `ice-3717.rs`.
Although fixes have already been made in #13216, it seems that he is a first-time contributor.
I thought it might be better for him to refer to my PR, so I created it accordingly.
Since this is my first contribution in a while, please let me know if there are any issues or required changes.
changelog: none
r! `@flip1995`
fix code blocks in doc comments inconsistently using 3 or 4 spaces of indentation
The metadata collector script was treating the space lines all start with as indentation. This caused code block's triple backticks to get a space in front of it, like this:
```
```rust
^ this space
```
Code after that that is indented with 4 spaces will only have 3 of those rendered.
Example (taken from [here](https://rust-lang.github.io/rust-clippy/master/index.html#/missing_panics_doc)):
```rust
...
pub fn divide_by(x: i32, y: i32) -> i32 {
if y == 0 { // 3 spaces
panic!("Cannot divide by 0") // 7 spaces
...
```
Also added 'compile_fail' alongside the other rustdoc directives (second code block [here](https://rust-lang.github.io/rust-clippy/master/index.html#/macro_metavars_in_unsafe) had no highlighting), fixed a doc comment using 'rs' instead of 'rust' and removed some spaces causing an extra missing space of indentation (see second code block [here](https://rust-lang.github.io/rust-clippy/master/index.html#/map_err_ignore)).
changelog: none
Replace `rustc_semver` with `rustc_session::RustcVersion`
Allows dropping a dependency but there is a behaviour change here, the following versions are no longer accepted:
* `1` (would need to be `1.0` or `1.0.0`)
* `1.0.0-alpha`
* `1.0.0-alpha.2`
* `1.0.0-beta`
But this seems unlikely to effect anybody, I did some GitHub searching and found no occurrences outside our UI tests
r? `@flip1995`
changelog: none
Add settings menu on clippy lints page
It looks like this (when the menu is expanded):
Follow-up of https://github.com/rust-lang/rust-clippy/pull/13178.
Someone pointed out that they should be able to disable the shortcuts on this page like it's the case for rustdoc and docs.rs. So here we go.
The first commit moves the style into its own file: it's much better for a web browser because it can then cache it.
The second one actually adds the new settings menu you can see above.
r? `@Alexendoo`
changelog: Add settings menu on clippy lints page
Fix case where doc_markdown is triggered on words ending with "ified"
Fixes#13097.
r? `@Alexendoo`
changelog: Fix case where doc_markdown is triggered on words ending with "ified"
[`macro_metavars_in_unsafe`]: recognize metavariables in tail expressions
Fixes#13219
`macro_metavars_in_unsafe` keeps track of the current "expansion depth" (incremented/decremented when entering/leaving a macro span) to tell if an expression from the root context is contained within a macro (see the doc comment I added for a hopefully better explanation)
Before this PR, we didn't increment said `expn_depth` for `unsafe` blocks within macros, because we already do that in `visit_stmt` anyway, so it would work fine for statements, but that's not enough for tail expressions of an unsafe block.
So we now also increment it for macro unsafe blocks.
Also updated the comment for `expn_depth` while I'm at it because "This is not necessary for correctness" isn't correct now that I think about it
------
changelog: none
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.
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
