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.
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`
Using `#[allow]` will also apply to child HIR nodes, while `#[expect]`
will ensure that the proper HIR node has been used for positioning the
lint.
changelog: none
changelog: [`implicit_saturating_sub`, `inverted_saturating_sub`]:
extend lints from local variables to side-effect free expressions
Noticed when #14308 introduced an implicit `saturating_sub` operation
and didn't get tagged.
Closes https://github.com/rust-lang/rust-clippy/issues/13169
Late lints now use a parent iter to check for `#[clippy::msrv]`
attributes instead of keeping track with `extract_msrv_attr`. This is
required for incremental lints since they run per module instead of per
crate so don't visit all the necessary attributes
As a basic optimisation if no `#[clippy::msrv]` attributes are
discovered in early passes the HIR access is skipped completely and just
the configured MSRV is used, for most code bases this will be the case
changelog: none
node_args doesn't work with struct literals and expr_ty must be used
instead
r? @y21
changelog: none
(No changelog, as this ICE didn't make it to the Rust repo, as it was
caught during the sync)
Fixes#14325
Out of cycle sync, as it is complicated and confusing to resolve merge
conflicts on the Rust side. This needs review for
eda3e649a41e0e73cb2e3ee6b98cbf8d7c12acae and
4d8766caaf11a14194406b8997243bb626000aae as well as the comment I'll
leave below.
changelog: none
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 https://github.com/rust-lang/rust-clippy/issues/14303
r? @y21
cc @jdonszelmann
changelog: Fix ICE in [`macro_use_import`] lint
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
