From feedback to the `arbitrary_source_item_ordering` lint after its
inclusion in clippy 1.82, making alphabetic ordering within module item
groups has turned out to be the most requested improvement. With this
improvement, it is possible to make the lint perform 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.
Implements parts of the suggestions from #13675. A catch-all-group is
still to be implemented.
changelog: [`arbitrary_source_item_ordering`]: Make alphabetic ordering
in module item groups optional (off by default)
fixes#13768
The existing implemention forgets to handle the binding mode (i.e. `ref`
and `ref mut`), so I just modified it to cover these cases.
changelog: [`manual_let_else`]: fix missing binding mode
I renamed the MSRV alias `MANUAL_DIV_CEIL` to `DIV_CEIL` in #14263, as
MSRV aliases should represent their capability rather than the lint
name. However, it seems this change was mistakenly overwritten in
#14022.
changelog: none
Adds the reasoning to the docs for this rule on why enums are generally
better for representing state machines than structs with many bool
fields.
changelog: [struct_excessive_bools]: Improve documentation
Currently, If a struct is `pub` and its field is private, and
`avoid-breaking-exported-api = true` (default), then
`struct_field_names` will not lint the field, even though changing the
field’s name is not a breaking change. This is because the
breaking-exported-api condition was checking the visibility of the
struct, not its fields (perhaps because the same code was used for
enums). With this change, Clippy will check the field’s effective
visibility only.
Note: This change is large because some functions were moved into an
`impl` to be able to access more configuration. Consider viewing the
diff with whitespace ignored.
changelog: [`struct_field_names`]: also check private fields of public
structs
The `has_eligible_receiver()` function had been adapted *a minima* when
the `sym::ControlFlow` diagnostic item has been added to rustc. This
refactors the function content to make its meaning clearer.
changelog: none
Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the
prelude instead of importing or qualifying them.
These functions were added to all preludes in Rust 1.80.
changelog: none
Remove Known problems section for `vec_box` since
[issue](https://github.com/rust-lang/rust-clippy/issues/3530#issuecomment-446058452)
> Vec<Box<T: Sized>> makes sense if T is a large type
can be handled
> The lint already checks that the type's size is lower than a threshold
to avoid linting on large types.
changelog: none
Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the
prelude instead of importing or qualifying them.
These functions were added to all preludes in Rust 1.80.
Since the error kind (`io::ErrorKind::other`) is in the root context,
the error message must be found in the root context as well to compute
the correct span to remove.
Fix#14346
changelog: [`io_error_other`]: fix non-applicable suggestion
r? @llogiq
Currently, If a struct is `pub` and its field is private, and
`avoid-breaking-exported-api = true` (default), then `struct_field_names`
will not lint the field, even though changing the field’s name is not a
breaking change. This is because the breaking-exported-api condition was
checking the visibility of the struct, not its fields (perhaps because
the same code was used for enums). With this change, Clippy will check
the field’s effective visibility only.
Note: This change is large because some functions were moved into an
`impl` to be able to access more configuration. Consider viewing the
diff with whitespace ignored.
It can be error-prone for developers to manually change literals with
mixed uppercase and lowercase letters into consistently all-lowercase or
all-uppercase literals. Therefore, this lint rule should suggest
alternative literals.
changelog: [`mixed_case_hex_literals`]: add alternative suggestions
Since the error kind (`io::ErrorKind::other`) is in the root context,
the error message must be found in the root context as well to compute
the correct span to remove.
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.
This PR:
- lints more case of raw pointer comparisons
- do not omit the named function to raw pointer conversion before
suggesting
- trigger the `ptr_eq` lint only if `cmp_null` doesn't trigger first, as
this is a more specialized version
- lints against `!=` in addition to `==`
The `ptr_eq` code has been moved from under `operators` to `ptr.rs`, in
order to benefit from factorization.
Fix#14337
changelog: [`ptr_eq`]: handle more cases
Closes#13306Closes#9925Closes#9470Closes#9305
Clippy gives wrong suggestions when the key is not `Copy`. As suggested
in #9925, in such cases Clippy will simply warn but no fix.
changelog: [`map_entry`]: fix wrong suggestions when key is not `Copy`
This feature was stabilized, so the FormatArgs lints should check if the MSRV of
the stabilization is met, rather than checking if the feature is enabled.
It is not possible to write a declarative macro, that produces an attribute w/o
an item attached to it. This means that the `check_item` will already insert the
span in the map, if it came from an expansion. So additionally checking if the
macro came from an expansion doesn't add anything here. So the
`check_attribute` function, and with that the problematic `attr.span()` call can
be completely removed.
Fixes#14303
