| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
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.
|
|
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
--> $DIR/attempted-access-non-fatal.rs:7:15
|
LL | let _ = 2.l;
| ^
|
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
|
LL - let _ = 2.l;
LL + let _ = 2.0f64;
|
```
|
|
The improvements are as follows:
- Remove an [unnecessary `compile-flags`
directive](https://github.com/rust-lang/rust-clippy/blob/f712eb5cdccd121d0569af12f20e6a0fabe4364d/tests/ui-toml/toml_disallowed_methods/conf_disallowed_methods.rs#L1)
in `tests/ui-toml/toml_disallowed_methods/conf_disallowed_methods.rs`
- Support replacements as suggested by @mitsuhiko in
https://github.com/rust-lang/rust-clippy/issues/7609#issuecomment-908632622
---
changelog: support replacements in `disallowed_methods`
|
|
clippy-subtree-update
|
|
|
|
|
|
requirement configurable (#13737)
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
|
|
Handle field attributes in suggestions
Fix adjacent code
Address review comments
https://github.com/rust-lang/rust-clippy/pull/13737#discussion_r1861352124
Address all review comments but one
This comment is not yet addressed: https://github.com/rust-lang/rust-clippy/pull/13737#discussion_r1874544907
`initializer_suggestions` -> `lint_inconsistent_struct_field_initializers`
|
|
clippy-subtree-update
|
|
Close #13842
changelog: [`indexing_slicing`]: add allow-indexing-slicing-in-tests
option to be able ignore at test
|
|
|
|
|
|
span rendering
|
|
Consider comments and bare delimiters the same as an "empty line" for purposes of hiding rendered code output of long multispans. This results in more aggressive shortening of rendered output without losing too much context, specially in `*.stderr` tests that have "hidden" comments.
|
|
|
|
`literal_string_with_formatting_args`
|
|
|
|
|
|
|
|
|
|
|
|
clippy-subtree-update
|
|
|
|
clippy-subtree-update
|
|
collect attribute spans early for disallowed macros
|
|
|
|
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-private-items = true
|
|
clippy-subtree-update
|
|
|
|
`module_name_repetitions`: don't warn if the item is in a private module.
Fixes <https://github.com/rust-lang/rust-clippy/issues/8524>.
There is still a warning (as there should be) if the item is reexported by name, but not by glob; that would require further work to examine the names in the glob, and I haven't looked into that.
Credit to `@Centri3` for suggesting approximately this simple fix in <https://github.com/rust-lang/rust-clippy/issues/8524#issuecomment-1729036149>. However, per later comment <https://github.com/rust-lang/rust-clippy/issues/8524#issuecomment-2035836495>, I am not making it configuration-dependent, but *always* checking public items in public modules only.
changelog: [`module_name_repetitions`]: don't warn if the item is in a private module.
|
|
|
|
|
|
clippy-subtree-update
|
|
|
|
clippy-subtree-update
|
|
Fixes <https://github.com/rust-lang/rust-clippy/issues/8524>.
There is still a warning (as there should be) if the item is reexported
by name, but not by glob; that would require further work to examine the
names in the glob, and I haven't looked into that.
Credit to @Centri3 for suggesting approximately this simple fix in
<https://github.com/rust-lang/rust-clippy/issues/8524#issuecomment-1729036149>.
However, per later comment <https://github.com/rust-lang/rust-clippy/issues/8524#issuecomment-2035836495>,
I am not making it configuration-dependent, but *always* checking public
items in public modules only.
|
|
|
|
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
|
|
* Check the path length first
* Use `is_from_proc_macro`
* Use symbols instead of strings when checking crate names
|
|
clippy-subtree-update
|
