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
Two optimizations have been done when checking for the context in which
to apply the lint:
- Checking for the mere presence of comments does not require building a
`String` with the comment to then check if it is empty and discard it.
- Checking for the presence of comment can be done after we have checked
that we do have a `if` construct that we intend to lint instead of for
every expression.
changelog: none
r? blyxyas
Two optimizations have been done when checking for the context in which
to apply the lint:
- Checking for the mere presence of comments does not require building a
`String` with the comment to then check if it is empty and discard it.
- Checking for the presence of comment can be done after we have checked
that we do have a `if` construct that we intend to lint instead of for
every expression.
This limits repeated lookups in pre-checks (to determine if a MSRV
should be checked), especially when those require locking up an
interner:
- The `core` crate is looked up once when creating the lint, instead of
comparing the crate name with `sym::core` at every check.
- `span.ctxt().outer_expn_data()` is lookup up only once.
changelog: none
r? blyxyas
Follow-up of https://github.com/rust-lang/rust-clippy/pull/15208.
This PR removes the CSS `bootstrap` dependency which contains 1504 CSS
rules and weights 16.1 kB minified. Considering we used less than 50 of
these rules, it's quite a waste.
So this time, there are minor UI changes:
* The "expand/collapse all" buttons icon changed. It now uses the one
from font-awesome. It's quite close but not exactly the same.
* The layout is slightly different (you need to switch between two tabs
to actually see the difference).
Before this PR:
<img width="719" height="515" alt="image"
src="https://github.com/user-attachments/assets/1f067046-4ee9-49ee-bf38-50a8bf9888f2"
/>
With this PR:
<img width="719" height="515" alt="image"
src="https://github.com/user-attachments/assets/80331c98-1a1e-418f-b481-5b3f5c276926"
/>
With this, we will be able to go even further on reducing the page size
next. =D
This time, the DOM size itself reduced a bit but the difference is too
small to be noteworthy.
r? @samueltardieu
changelog: Remove CSS bootstrap dependency
This limits repeated lookups in pre-checks (to determine if a MSRV
should be checked), especially when those require locking up
an interner:
- The `core` crate is looked up once when creating the lint, instead of
comparing the crate name with `sym::core` at every check.
- `span.ctxt().outer_expn_data()` is lookup up only once.
changelog: [`collapsible_else_if`]: fix suggestion when inner `if` as
wrapped in parentheses
changelog: [`collapsible_if`]: fix suggestion when inner `if` as wrapped
in parentheses
fixes https://github.com/rust-lang/rust-clippy/issues/15303
I'm sure this is a bit dirty, but don't currently see a better way.
When I first tried contributing to clippy,
I encountered the problem that a lot of lint suggestions overlapped with
existing lints, so I would spend a bunch of time implementing something
only to figure out it wasn't actually needed.
The "comparison with existing lints" field should hopefully reduce this
somewhat, while not incresing the burden of
requesting a new lint too much due to not being mandatory.
changelog: none
The `unnecessary_sort_by` lint displays different method names in
message and suggestion, which is a bit confusing.
Also got a question about `UNNECESSARY_SORT_BY` lint definition. Should
we extend its message to also cover *_unstable_* methods?
changelog: [`unnecessary-sort-by`]: sort method consistency in message
and suggestion
