new lint: `source_item_ordering`
changelog: [`source_item_ordering`]: Introduced a new restriction lint that checks the ordering of items in Modules, Enums, Structs, Impls and Traits.
From the written documentation:
> Why restrict this?
> Keeping a consistent ordering throughout the codebase helps with working as a team, and possibly improves maintainability of the codebase. The idea is that by defining a consistent and enforceable rule for how source files are structured, less time will be wasted during reviews on a topic that is (under most circumstances) not relevant to the logic implemented in the code. Sometimes this will be referred to as "bike-shedding".
>
> Keep in mind, that ordering source code alphabetically can lead to reduced performance in cases where the most commonly used enum variant isn't the first entry anymore, and similar optimizations that can reduce branch misses, cache locality and such. Either don't use this lint if that's relevant, or disable the lint in modules or items specifically where it matters. Other solutions can be to use profile guided optimization (PGO), or other advanced optimization methods.
I tried to build it as configurable as possible, as such a highly opinionated lint should be adjustable to personal opinions.
I'm open to any input and will be available both here and on the zulip for communication. In the meantime I'll be testing this lint against my own code-bases, which I've (manually) kept ordered with the default config, to see how well it works in practice.
And lastly, a big thanks to the community for making clippy the best linter there is!
check std::panic::panic_any in panic lint
close#13292
This PR detects `std::panic::panic_any` in panic lint.
changelog: check std::panic::panic_any in panic lint
[`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
* Construct lint passes by taking `Conf` by reference.
* Use `HashSet` configs in less places
* Move some `check_crate` code into the pass constructor when possible.
Until now, the lint only emitted a warning, when breaking public API. Now it
doesn't lint at all when the config value is not set to `false`, bringing it in
line with the other lints using this config value.
Also ensures that this config value is documented in the lint.
The original message ("unsafe function's docs miss `# Safety` section")
reads quite awkwardly. I've changed it to "unsafe function's docs are missing
a `# Safety` section" to have it read better.
Signed-off-by: Paul R. Tagliamonte <paultag@gmail.com>
This adds a `àllow-useless-vec-in-test` configuration which, when set
to `true` will allow the `useless_vec` lint in `#[test]` functions and
code within `#[cfg(test)]`. It also moves a `is_in_test` helper to
`clippy_utils`.
