Per the root readme, `clippy::style` is a category with
> code that should be written in a more idiomatic way
description.
The code this lint guards from may be much worse than badly styled:
```rs
use std::sync::LazyLock;
// `const` instead of `static` causes `dbg!` to be printed 10 times
// instead of one.
const LICENSE_FILE_NAME_REGEX: LazyLock<String> = LazyLock::new(|| {
dbg!("I am a large regex initialized in a lazy lock!");
format!("Hello {}", "World".to_string())
});
fn main() {
for _ in 0..10 {
let _ = LICENSE_FILE_NAME_REGEX.split(" ");
}
}
```
In large projects, it's unfortunate but sometimes possible to see style
lints suppressed with
```toml
[workspace.lints.clippy]
style = { level = "allow", priority = -1 }
```
effectively turning off crucial checks for the code like above.
To keep them, promote this lint to `clippy::suspicious`:
> code that is most likely wrong or useless
category that has the same, `warn` default level, thus not failing on
false-positives which lead to
https://github.com/rust-lang/rust-clippy/issues/5863
---
changelog: [`declare_interior_mutable_const`]: promote lint's category
to `clippy::suspicious`
Per the root readme, `clippy::style` is a category with
> code that should be written in a more idiomatic way
description.
The code this lint guards from may be much worse than badly styled:
```rs
use std::sync::LazyLock;
// `const` instead of `static` causes `dbg!` to be printed 10 times
// instead of one.
const LICENSE_FILE_NAME_REGEX: LazyLock<String> = LazyLock::new(|| {
dbg!("I am large regex initialized in a lazy lock!");
format!("Hello {}", "World".to_string())
});
fn main() {
for _ in 0..10 {
let _ = LICENSE_FILE_NAME_REGEX.split(" ");
}
}
```
In large projects, it's unfortunate but sometimes possible to see style lints suppressed with
```toml
[workspace.lints.clippy]
style = { level = "allow", priority = -1 }
```
effectively turning off crucial checks for the code like above.
To keep them, promote this lint to `clippy::suspicious`:
> code that is most likely wrong or useless
category that has the same, `warn` default level, thus not failing on false-positives which lead to https://github.com/rust-lang/rust-clippy/issues/5863
JetBrains has transitioned from the IntelliJ Rust plugin to RustRover as
their dedicated Rust IDE. This updates the documentation to reflect this
change while maintaining backward compatibility with the existing `cargo
dev setup intellij` command.
Changes:
- Replace IntelliJ Rust references with RustRover in CONTRIBUTING.md
- Update links to point to official RustRover homepage
- Update development guide in book/src/development/basics.md
- Keep existing command names for backward compatibility
**Question**: Do we also need to change the `intellij` command to
`rustrover`?
fixesrust-lang/rust-clippy#15406
changelog: Update CONTRIBUTING.md to reference RustRover instead of
deprecated IntelliJ Rust
minor fix in `from_str_radix_10` lint, `is_type_diagnostic_item` only
checks `Adt`, use `.is_str()` instead
changelog: [`from_str_radix_10`]: properly lint references to `&str` as
well
combine two similar arms
use in `eager_transmute`
use in `double_ended_iterator_last`
use different numbers in the new test case to avoid possible confusion
move the other "unfixable" case as well; it shouldn't lint anyway, so
having it in the main test file is fine
```
changelog: [`doc-valid-idents`]: add "PowerPC" to the list of words not considered as identifiers
```
---
changelog: add "PowerPC" to the list of words not considered as
identifiers by `doc-valid-idents` rule
JetBrains has transitioned from the IntelliJ Rust plugin to RustRover
as their dedicated Rust IDE. This updates the documentation to reflect
this change while maintaining backward compatibility with the existing
cargo dev setup intellij command.
Changes:
- Replace IntelliJ Rust references with RustRover in CONTRIBUTING.md
- Update links to point to official RustRover homepage
- Update development guide in book/src/development/basics.md
- Keep existing command names for backward compatibility
changelog: [infinite_loop]: Improve handling of infinite loops in async
blocks
Fixrust-lang/rust-clippy#14000
This PR refines the [infinite_loop] lint to avoid false positives when
infinite loops occur inside async blocks that are not awaited (such as
those that are spawned or assigned to variables for later use). The lint
will now only trigger when the async block containing the loop is
directly awaited.
This is a small thing I noticed while looking into
https://github.com/rust-lang/rust-clippy/issues/8014. Since I ultimately
decided not to change the code as a response to the issue, I'm now left
with this one commit, and I feel a bit unsure about making a PR just for
that. This is a problem I have relatively often, so I'd like to know
whether I should to batch these small changes somehow, or whether these
small PRs are fine after all
changelog: none
Ada Alakbarova