`warn_on_all_wildcard_imports` should warn on all wildcard imports,
including the reexported ones.
Fix#13660
changelog: [`warn_on_all_wildcard_imports`]: when asked to warn on all
wildcard imports, include the reexported ones
Replace the use of `Sugg::ast()` which prevented combining `if`
together when they contained comments by span manipulation.
A new configuration option `lint_commented_code`, which is `true` by
default, opts out from this behavior.
From feedback to this lint after its inclusion in clippy 1.82, this has
turned out to be the most requested improvement. With this improvement,
it is possible to make the lint check certain top-level structural
checks on modules (e.g. use statements and module inclusions at the top),
but still leaving everything else up to the developer.
- The name of an MSRV alias should describe its functionality, and it is
not appropriate for it to be the same as the name of the lint that uses
it.
- Additionally, while `manual_div_ceil` allows setting MSRV, this is not
correctly reflected in the configuration information.
changelog: none
By default, do not lint `.unwrap()` and `.expect(…)` in always const
contexts, as a failure would be detected at compile time anyway.
New options `allow_expect_in_consts` and `allow_unwrap_in_consts`,
defaulting to `true`, can be turned unset to still lint in always const
contexts.
Using `Vec::extend(std::iter::repeat_n(item, N))` allows to use the more
natural number of elements to add `N`, as is probably done in the original
loop, instead of computing the difference between the existing number of
elements and the wanted one.
Before MSRV 1.82, the older suggestion to use `Vec::resize()` is still
issued.
Fixes#11846.
This PR has three commits:
- The first commit adds an `initializer-suggestions` configuration to
control suggestion applicability when initializers are present. The
following are the options:
- "none": do not suggest
- "maybe-incorrect": suggest, but do not apply suggestions with `--fix`
- "machine-applicable": suggest and apply suggestions with `--fix`
- The second commit fixes suggestions to handle field attributes
(problem [noticed by
@samueltardieu](https://github.com/rust-lang/rust-clippy/pull/13737#discussion_r1859261645)).
- The third commit adds `initializer-suggestions = "machine-applicable"`
to Clippy's `clippy.toml` and applies the suggestions. (Nothing seems to
break.)
---
changelog: make `inconsistent_struct_constructor` "all fields are
shorthand" requirement configurable
It's becoming more and more common to see people including markdown
files in their code using `doc = include_str!("...")`, which is great.
However, often there is no condition on this include, which is not great
because it slows down compilation and might trigger recompilation if
these files are updated.
This lint aims at fixing this situation.
changelog: Add new lint `doc_include_without_cfg`
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!
