Currently this only provides the feature to auto-update the nightly version in
the `rust-toolchain` file and the `clippy_utils/README.md` file. The actual sync
to and from the Rust repo will be added with the move to Josh.
There was some dependence between the different subcommands of clippy_dev. And
this dependence will increased with the introduction of the sync and release
subcommands. This moves the common functions to a `utils` module, to decouple
the other modules.
Follow up to https://github.com/rust-lang/rust-clippy/pull/13691
Adds metadata to the `clippy_utils/Cargo.toml`, which is mostly copied
from the root `Cargo.toml`.
Adds a `README.md` file listing the nightly version `clippy_utils` can
be used with, mentions that there are no stability guarantees and the
license.
The next PR will add automation to update the nightly toolchains in
those files and the versions in the `Cargo.toml`s.
cc https://github.com/rust-lang/rust-clippy/issues/13556
changelog: none
Two changes to `redundant_guards`:
- Lint float literals. We used to do that before but that was changed in
#11305 because at the time there was a future compat warning and it was
planned to make pattern matching floats a hard error.
In rust-lang/rust#116284 it was decided to actually remove the lint and
only make matching `NAN` specifically a hard error. The `NAN` part isn't
relevant/important here because this PR only changes what literals are
warned and `f64::NAN` isn't a literal, but I've added a test anyway to
make sure we continue to not lint there.
- Don't lint CStr literals because that can't be a pattern right now
(fixes#13681)
changelog: none
Add support for `#[clippy::format_args]` attribute that can be attached
to any macro to indicate that it functions the same as the built-in
format macros like `format!`, `println!` and `write!`
---
changelog: Enhancement: [`format_in_format_args`],
[`recursive_format_impl`], [`to_string_in_format_args`],
[`uninlined_format_args`], [`unused_format_specs`]: Recognizes
`#[clippy::format_args]` to support custom 3rs party format macros.
Add support for `#[clippy::format_args]` attribute that can be attached to any macro to indicate that it functions the same as the built-in format macros like `format!`, `println!` and `write!`
In preparation of #13556, I want to remove the dependency on
`clippy_config`, as I don't think that we want to publish that for
outside consumers. To do this the 2 dependecies on `clippy_config` had
to be removed:
1. The MSRV implementation was in `clippy_config`, but was required in
`qualify_min_const`. I think exposing the MSRV infrastructure and the
MSRVs we defined might also be helpful for `clippy_utils` users. I don't
see why it should not be able to live in `clippy_utils` from a technical
point of few.
2. The `create_disallowed_map` function that took in a
`clippy_utils::types::DisallowedPath` is moved to the `DisallowedPath`
implementation. This also fits there and is only useful for Clippy and
not in `clippy_utils` for external consumers.
`clippy_config` now depends in `clippy_utils`, so the dependecy just got
reversed. But having the `clippy_utils` crate as the base of the
dependency tree in Clippy makes sense.
changelog: none
Closes#6947
This changes the lint to allow futures which are not `Send` as a result
of a generic type parameter not having a `Send` bound and only lint
futures that are always `!Send` for any type, which I believe is the
more useful behavior (like the comments in the linked issue explain).
This is still only a heuristic (I'm not sure if there's a more general
way to do this), but it should cover the common cases I could think of
(including the code examples in the linked issue)
changelog: [`future_not_send`]: allow conditional `Send` futures
Closes https://github.com/rust-lang/rust-clippy/issues/10118
This lint checks `map_or` method calls to check if they can be
consolidated down to something simpler and/or more readable.
For example, the code
```rs
let x = Some(5);
x.map_or(false, |n| n == 5)
```
can be rewritten as
```rs
let x = Some(5);
x == Some(5)
```
In addition, when the closure is more complex, the code can be altered
from, say,
```rs
let x = Ok::<Vec<i32>, i32>(vec![5]);
x.map_or(false, |n| n == [5])
```
into
```rs
let x = Ok::<Vec<i32>, i32>(vec![5]);
x.is_some_and(|n| n == [5])
```
This lint also considers cases where the `map_or` can be chained with
other method calls, and accommodates accordingly by adding extra
parentheses as needed to the suggestion.
changelog: add new lint `unnecessary_map_or`
Proper support for cross-crate recursive const stability checks
~~Stacked on top of https://github.com/rust-lang/rust/pull/132492; only the last three commits are new.~~
In a crate without `staged_api` but with `-Zforce-unstable-if-unmarked`, we now subject all functions marked with `#[rustc_const_stable_indirect]` to recursive const stability checks. We require an opt-in so that by default, a crate can be built with `-Zforce-unstable-if-unmarked` and use nightly features as usual. This property is recorded in the crate metadata so when a `staged_api` crate calls such a function, it sees the `#[rustc_const_stable_indirect]` and allows it to be exposed on stable. This, finally, will let us expose `const fn` from hashbrown on stable.
The second commit makes const stability more like regular stability: via `check_missing_const_stability`, we ensure that all publicly reachable functions have a const stability attribute -- both in `staged_api` crates and `-Zforce-unstable-if-unmarked` crates. To achieve this, we move around the stability computation so that const stability is computed after regular stability is done. This lets us access the final result of the regular stability computation, which we use so that `const fn` can inherit the regular stability (but only if that is "unstable"). Fortunately, this lets us get rid of an `Option` in `ConstStability`.
This is the last PR that I have planned in this series.
r? `@compiler-errors`
Fixes#13670.
Bug was that I forgot to add the comparison with the included file
content length...
changelog: Fix `large_include_file` lint being triggered all the time by
doc comments
The `identity_op` lint was suggesting code fixes that resulted in
incorrect or broken code, due to missing parenthesis in the fix that
changed the semantics of the code.
For a binary expression, `left op right`, if the `left` was redundant,
it would check if the right side needed parenthesis, but if the `right`
was redundant, it would just assume that the left side did not need
parenthesis.
This can result in rustfix generating broken code and failing, or
generating code that has different behavior than before the fix. e.g.
`-(x + y + 0)` would turn into `-x + y`, changing the behavior, and
`1u64 + (x + y + 0i32) as u64` where `x: i32` and `y: i32` would turn
into `1u64 + x + y as u64`, creating an error where `x` cannot be added
to the other values, as it was never cast to `u64`.
This commit fixes both of these problems by always checking the
non-redundant child of a binary expression for needed parenthesis.
fixes#13470
changelog: [`identity_op`]: Fix suggested code that is broken or has
changed behavior
Now that lints can add @eval_always at the end of their definition, the lint
declaration might not end right after the description. The `update_lints`
command can skip everything that comes after that.
The author lint is not an internal lint, and should also be enabled, when Clippy
is distributed through rustup. This moves the author lint test cases back to
tests/ui.
