Apply "polymorphization at home" to RawVec
The idea here is to move all the logic in RawVec into functions with explicit size and alignment parameters. This should eliminate all the fussing about how tweaking RawVec code produces large swings in compile times.
This uncovered https://github.com/rust-lang/rust-clippy/issues/12979, so I've modified the relevant test in a way that tries to preserve the spirit of the test without tripping the ICE.
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.
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
