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
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
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.
needless_continue: check labels consistency before warning
changelog: [`needless_continue`]: check labels before warning about `continue` as the last statement in a loop body
Fix#13641
no_mangle attribute requires unsafe in Rust 2024
Tests without unsafe must not run in edition 2024. Also, error messages have been modified to include the full attribute, so that a use of `#[unsafe(no_mangle)]` does not produce an error message containing `#[no_mangle]`.
changelog: [`no_mangle_attribute`]: handle `#[unsafe(no_mangle)]` as well
Don't lint unnamed consts and nested items within functions in `missing_docs_in_private_items`
With this change we no longer require doc comments for `const _: ()` items as well as nested items in functions or other bodies. In both of those cases, rustdoc generates no documentation even with `--document-private-items`.
Fixes#13427 (first commit)
Fixes#13298 (second commit)
cc https://github.com/rust-lang/rust-clippy/issues/5736#issuecomment-668524296
changelog: [`missing_docs_in_private_items`]: avoid linting in more cases where rustdoc generates no documentation
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 either rustfix generating broken code and failing,
or 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 broken code where `x` cannot
be added to the other values, as it was never cast to `u64`.
This commit fixes both of these cases by always checking the
non-redundant child of a binary expression for needed parenthesis, and
makes it so if we need parenthesis, but they already exist, we don't add
any redundant ones.
Fixes#13470
new lint: `source_item_ordering`
changelog: [`source_item_ordering`]: Introduced a new restriction lint that checks the ordering of items in Modules, Enums, Structs, Impls and Traits.
From the written documentation:
> Why restrict this?
> Keeping a consistent ordering throughout the codebase helps with working as a team, and possibly improves maintainability of the codebase. The idea is that by defining a consistent and enforceable rule for how source files are structured, less time will be wasted during reviews on a topic that is (under most circumstances) not relevant to the logic implemented in the code. Sometimes this will be referred to as "bike-shedding".
>
> Keep in mind, that ordering source code alphabetically can lead to reduced performance in cases where the most commonly used enum variant isn't the first entry anymore, and similar optimizations that can reduce branch misses, cache locality and such. Either don't use this lint if that's relevant, or disable the lint in modules or items specifically where it matters. Other solutions can be to use profile guided optimization (PGO), or other advanced optimization methods.
I tried to build it as configurable as possible, as such a highly opinionated lint should be adjustable to personal opinions.
I'm open to any input and will be available both here and on the zulip for communication. In the meantime I'll be testing this lint against my own code-bases, which I've (manually) kept ordered with the default config, to see how well it works in practice.
And lastly, a big thanks to the community for making clippy the best linter there is!
[`infinite_loops`]: fix incorrect suggestions on async functions/closures
closes: #12338
I intend to fix this in #12421 but got distracted by some other problems in the same lint, delaying the process of closing the actual issue. So here's a separated PR that only focus on the issue and nothing else.
---
changelog: [`infinite_loops`]: fix suggestion error on async functions/closures
Cleanup code suggestion for `into_iter_without_iter`
Reorder the suggested code for the `IntoIterator` to match the ordering of the trait declaration:
```rust
impl IntoIterator for ... {
type Item = ...;
type IntoIter = ...;
```
changelog: none
Extend `large_include_file` lint to also work on attributes
I realized randomly while working on another lint that `large_include_file` was not emitted on attributes. This PR fixes that.
changelog: Extend `large_include_file` lint to also work on attributes
Add 'CoAP' to doc-valid-idents
CoAP is a name of a network protocol common in embedded systems; one would talk in documentation about "a CoAP server" or "a CoAP client" without referring to a specific type.
This PR fixes false positives that arise from that use.
changelog: [`doc_markdown`]: Add CoAP to `doc-valid-idents`.
As this review is identical in structure to https://github.com/rust-lang/rust-clippy/pull/13460, I'm asking for a the same reviewer (if that works):
r? `@Centri3`
Reorder the suggested code for the `IntoIterator` to match the ordering of the trait declaration:
```rust
impl IntoIterator for ... {
type Item = ...;
type IntoIter = ...;
```
Fix allow_attributes when expanded from some macros
fixes#13349
The issue here was that the start pattern being matched on the original source code was not specific enough. When using derive macros or in the issue case a `#[repr(C)]` the `#` would match the start pattern meaning that the expanded macro appeared to be unchanged and clippy would lint it.
The change I made was to make the matching more specific by matching `#[ident` at the start. We still need the second string to match just the ident on its own because of things like `#[cfg_attr(panic = "unwind", allow(unused))]`.
I also noticed some typos with start and end, these code paths weren't being reached so this doesn't fix anything.
changelog: FP: [`allow_attributes`]: don't trigger when expanded from some macros
This lint checks for code that looks like
```rust
let something : Vec<_> = (0..100).map(|_| {
1 + 2 + 3
}).collect();
```
which is more clear as
```rust
let something : Vec<_> = std::iter::repeat_with(|| {
1 + 2 + 3
}).take(100).collect();
```
or
```rust
let something : Vec<_> =
std::iter::repeat_n(1 + 2 + 3, 100)
.collect();
```
That is, a map over a range which does nothing with the parameter
passed to it is simply a function (or closure) being called `n`
times and could be more semantically expressed using `take`.
Lint against getting pointers from immediately dropped temporaries
Fixes#123613
## Changes:
1. New lint: `dangling_pointers_from_temporaries`. Is a generalization of `temporary_cstring_as_ptr` for more types and more ways to get a temporary.
2. `temporary_cstring_as_ptr` is removed and marked as renamed to `dangling_pointers_from_temporaries`.
3. `clippy::temporary_cstring_as_ptr` is marked as renamed to `dangling_pointers_from_temporaries`.
4. Fixed a false positive[^fp] for when the pointer is not actually dangling because of lifetime extension for function/method call arguments.
5. `core::cell::Cell` is now `rustc_diagnostic_item = "Cell"`
## Questions:
- [ ] Instead of manually checking for a list of known methods and diagnostic items, maybe add some sort of annotation to those methods in library and check for the presence of that annotation? https://github.com/rust-lang/rust/pull/128985#issuecomment-2318714312
## Known limitations:
### False negatives[^fn]:
See the comments in `compiler/rustc_lint/src/dangling.rs`
1. Method calls that are not checked for:
- `temporary_unsafe_cell.get()`
- `temporary_sync_unsafe_cell.get()`
2. Ways to get a temporary that are not recognized:
- `owning_temporary.field`
- `owning_temporary[index]`
3. No checks for ref-to-ptr conversions:
- `&raw [mut] temporary`
- `&temporary as *(const|mut) _`
- `ptr::from_ref(&temporary)` and friends
[^fn]: lint **should** be emitted, but **is not**
[^fp]: lint **should not** be emitted, but **is**
