The lint for function calls was previously restricted to functions
taking exactly one argument. This was not documented.
Generalizing the lint to an arbitrary number of arguments in the
function call requires special casing some macro expansions from the
standard library. Macros such as `panic!()` or `assert_eq!()` exist
since Rust 1.0.0, but modern stdlib expand those macros into calls to
functions introduced in later Rust versions. While it is desirable to
lint code inside macros, using MSRV-incompatible functions coming from
`core` in macro expansions has been special-cased to not trigger this
lint.
Also, code coming from compiler desugaring may contain function calls
(for example, `a..=b` is now desugared into `RangeInclusive::new(a, b)`.
Those should not be linted either as the compiler is allowed to use
unstable function calls.
Fix#14212
changelog: [`incompatible_msrv`]: lint function calls with any argument
count
If types such as `Option<Option<String>>` are not used by value, then
`Option<Option<&String>>` will be suggested, instead of
`Option<&Option<String>>`.
changelog: [`needless_pass_by_value`]: suggest using a reference on the
innermost `Option` content
fix#14375
Last part of https://github.com/rust-lang/rust-clippy/pull/11421.
Now all ui tests require annotations.
The change in `ui_test` is to add `ICE:` errors.
changelog: Make internals ui tests annotations mandatory
r? @flip1995
If types such as `Option<Option<String>>` are not used by value, then
`Option<Option<&String>>` will be suggested, instead of
`Option<&Option<String>>`.
Follow-up of https://github.com/rust-lang/rust-clippy/pull/11421.
I can't yet make the annotations mandatory because there is an issue
with `tests/ui-internal/custom_ice_message.rs`: the error message is not
emitted as JSON, meaning that we can't match it with `ui_test`. I need
to check if it's a bug in rustc or if `ui_test` needs to handle this
case somehow.
changelog: Add missing tests annotations for `ui-internal`
r? @flip1995
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
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
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`
The lint for function calls was previously restricted to functions taking
exactly one argument. This was not documented.
Generalizing the lint to an arbitrary number of arguments in the function
call requires special casing some macro expansions from the standard
library. Macros such as `panic!()` or `assert_eq!()` exist since Rust
1.0.0, but modern stdlib expand those macros into calls to functions
introduced in later Rust versions. While it is desirable to lint code
inside macros, using MSRV-incompatible functions coming from `core`
in macro expansions has been special-cased to not trigger this lint.
Also, code coming from compiler desugaring may contain function calls
(for example, `a..=b` is now desugared into `RangeInclusive::new(a,
b)`. Those should not be linted either as the compiler is allowed to
use unstable function calls.
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
