Fixesrust-lang/rust-clippy#15192 by adding checks for no_std while
giving out Box recommendation
```
changelog: [`large_enum_variant`]: Dont suggest `Box` in `no_std` mode
```
- Updated the `help:` text to include a more general suggestion
- Ensures compatibility with `#[no_std]` environments where boxing is
still possible via `alloc`.
This PR supersedes #14328 following the [2025-03-18 Clippy meeting
discussion](https://rust-lang.zulipchat.com/#narrow/channel/257328-clippy/topic/Meeting.202025-03-18/with/506527762).
It uses a simpler approach than what was proposed initially in #14328
and does not add new options.
First, it documents how `cfg_attr` can be used to change the MSRV
considered by Clippy to trigger the lint. This allows the MSRV to be
feature gated, or to be raised in tests.
Also, the lint stops warning about items which have been explicitly
allowed through a rustc feature. This works even if the feature has been
stabilized since. It allows using an older compiler with some features
turned on, as is done in Rust for Linux. This fixes#14425.
Then, if the lint triggers, and it looks like the code is located below
a `cfg` or `cfg_attr` attribute, an additional note is issued, once, to
indicate that the `clippy::msrv` attribute can be controlled by an
attribute.
Finally, the lint is extended to cover any path, not just method and
function calls. For example, enumeration variants, or constants, were
not MSRV checked. This required replacing two `u32::MAX` by
`u32::max_value()` in MSRV-limited tests.
An extra commit adds a TODO for checking the const stability also, as
this is not done right now.
@Centri3 I'll assign this to you because you were assigned #14328 and
you were the one who nominated the issue for discussion (thanks!), but
of course feel free to reroll!
r? @Centri3
changelog: [`incompatible_msrv`]: better documentation, honor the
`features` attribute, and lint non-function entities as well
The first non-MSRV-compatible item located under a `#[cfg(…)]` or
`#[cfg_attr(…)]` attribute will get an additional note suggesting
changing `#[clippy::msrv]` locally.
A representation attribute `#[repr(…)]` might indicate that the ordering
of the fields or the variants is dictated by the API the code is
interfacing with. Better not lint with `arbitrary_source_item_ordering`
in this case.
changelog: [`arbitrary_source_item_ordering`]: do not lint inside items
with `#[repr]` attribute
Adds an internal lint to check for `#[derive(serde::Deserialize)]`
without
[`#[serde(deny_unknown_fields)]`](https://serde.rs/container-attrs.html#deny_unknown_fields).
Today, if you run Clippy with the following clippy.toml, Clippy will
produce a warning, but there will be no accompanying note:
```toml
# In the following configuration, "recommendation" should be "reason" or "replacement".
disallowed-macros = [
{ path = "std::panic", recommendation = "return a `std::result::Result::Error` instead" },
]
```
```sh
$ cargo clippy
Checking a v0.1.0 (/home/smoelius/tmp/a)
warning: use of a disallowed macro `std::panic`
--> src/lib.rs:2:5
|
2 | panic!();
| ^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#disallowed_macros
= note: `#[warn(clippy::disallowed_macros)]` on by default
```
The underlying problem is: the enum that derives `serde::Deserialize`
([`DisallowedPathEnum`](81643e297c/clippy_config/src/types.rs (L47)))
does not have the attribute `#[serde(deny_unknown_fields)]`.
This lint identifies such problems by checking trait `impl`s. An
alternative I considered was to walk `clippy_config::conf::Conf`
directly. However, that would not catch the `DisallowedPathEnum` case
because it [is not used in `Conf`
directly](81643e297c/clippy_config/src/types.rs (L31)).
Just to be clear, no one asked for this. So I hope the maintainers do
not mind.
changelog: none
changelog: [`type_repetition_in_bounds`]: include all generic bounds in
suggestion, clearer message which now includes the repeated type name
Fixesrust-lang/rust-clippy#14744
fixes#14413
add allow_unused config to missing_docs_in_private_items for underscored
field
changelog: [`missing_docs_in_private_items`]: add allow_unused config to
missing_docs_in_private_items for underscored field
Explaination (quoted from the issue's author): When writing structures
that must adhere to a specific format (such as memory mapped I/O
structures) there are inevitably fields that are "reserved" by
specifications and thus need no documentation. In cases where private
docs are preferred but reserved fields need no explanation, having to
#[allow/expect] this lint removes the ability to check for otherwise
used fields' documentation.
The MSRV being for crates targeting 1.85-1.87 on edition 2024
This enables the lint for regular nightly users without the feature gate
enabled
r? @samueltardieu
Fixes https://github.com/rust-lang/rust-clippy/issues/14678
changelog: none
A representation attribute `#[repr(…)]` might indicate that the ordering
of the fields or the variants is dictated by the API the code is
interfacing with. Better not lint with `arbitrary_source_item_ordering`
in this case.
Until `if let` chains are stabilized, we do not collapse them together
or with other `if` expressions unless the `let_chains` feature is
enabled. This is the case for example in Clippy sources.
This was made possible by converting the `collapsible_if` to a late lint
to get access to the set of enabled features. This allows this PR to
supersede #14455 and no longer require an additional configuration
option.
The three commits are, in order:
- a conversion of the existing early lint to a late lint, with no new
feature or tests changes
- the addition of the `let_chains` feature detection and action, and
tests
- the application of the enhanced lint to Clippy sources (136 files
modified)
changelog: [`collapsible_if`]: recognize the rust compiler `let_chains`
feature
r? @flip1995
Until `if let` chains are stabilized, we do not collapse them together
or with other `if` expressions unless the `let_chains` feature is
enabled. This is the case for example in Clippy sources.
This extra condition prevents a problem when removing the '}' in:
```rust
( // There was an opening bracket after the parenthesis, which has been removed
// This is a comment
})
```
Removing the whitespaces, including the linefeed, before the '}', would put the
closing parenthesis at the end of the `// This is a comment` line, which would
make it part of the comment as well. In this case, it is best to keep the span
on the '}' alone.
This lint was downgraded to `pedantic` in part because rust-analyzer was not fully supporting it at the time per #10087. The support has been added over [a year ago](https://github.com/rust-lang/rust-analyzer/issues/11260), so seems like this should be back to style.
Another source of the initial frustration was fixed since then as well - this lint does not trigger by default in case only some arguments can be inlined.
This PR does two things:
- It renames `inconsistent_struct_constructor`'s configuration from
`lint-inconsistent-struct-field-initializers` to
`check-inconsistent-struct-field-initializers`. (I should have suggested
`check-...` in
[#13737](https://github.com/rust-lang/rust-clippy/pull/13737#discussion_r1875118516).)
- It causes Clippy to no longer suggest deprecated configurations.
(Previously, Clippy would suggest `cyclomatic-complexity-threshold`, for
example.)
r? @y21
changelog: Rename `lint-inconsistent-struct-field-initializers` to
`check-inconsistent-struct-field-initializers`
changelog: No longer suggest deprecated configurations
