Supersedes https://github.com/rust-lang/rust-clippy/pull/15482
I wasn't able to get `is_const_method` to work, so for now we just don't
suggest `=` in const context.
changelog: [`equatable_if_let`]: don't suggest `=` in const context
This introduces a new lint that aims to check for missing terminal
punctuation in doc comments.
## Lint scope and motivation
It partially addresses
https://github.com/rust-lang/rust-clippy/issues/8371 by currently
focusing on the case that is both the easiest to look for without
advanced NLP capacities and still very useful: missing punctuation at
the end of the last sentence of doc comments. This is particularly
useful when working in a team to enforce a style guide and make sure all
doc comments end with some kind of punctuation, which is often forgotten
in the case of short, single-sentence doc comments. The lint is biased
towards avoiding false positives so it can be easily adopted without
requiring an excessive number of `#[expect]` attributes.
It is currently only concerned with Latin languages, but adding support
for `。` for instance should be very easy.
Even if consistently ending doc comments (even very short ones) with
punctuation is somewhat of an opinion, it seems sufficiently
well-established, [at least in the
`std`](https://github.com/rust-lang/rust/pull/91886), to warrant its own
lint, even if of course it would be allow-by-default.
## Lint category and possible evolution
Because it is unclear how useful and more complex it would be to also
look for missing punctuation at the end of *each* Markdown paragraphs, I
opted for the `nursery` category for now. My understanding of [the
stability
guarantees](https://github.com/rust-lang/rfcs/blob/master/text/2476-clippy-uno.md#stability-guarantees)
is that would it not be acceptable to add such capability later if it
was part of `pedantic` or `restriction` categories right away. I tried
to make sure the lint name allows this kind of iterative evolution.
## Testing
I ran the lint against the `core` library which led me to introduce a
few special cases (which seem common enough) to avoid false positives:
e.g., the last sentence being in parentheses. After excluding specific
modules which should likely be excluded (e.g., `core_arch`,
`intrinsincs`), it currently finds a bit more than 200 errors in the
`core` library.
This lint also helped find issues with a few doc comments, which [are
now fixed](https://github.com/rust-lang/rust/pull/146136).
## How to review this PR
I suppose it is easier to have a look at the UI tests first before
checking the implementation.
---
*Please write a short comment explaining your change (or "none" for
internal only changes)*
changelog: add new lint [`doc_paragraphs_missing_punctuation`]
Resolves https://github.com/rust-lang/rust-clippy/issues/15321
Unresolved questions:
- [ ] I did implement support for nested field accesses, but I'm not
sure if that's desired
- It brings some additional complexity, though not too much
- It might be surprising for the user to get a lint on a direct field
access, but not a nested one
- It's unclear how often such nested case comes up
changelog: [`unnecessary_unwrap`]: lint field accesses
changelog: [`panicking_unwrap`]: lint field accesses
changelog: [`sliced_string_as_bytes`]: don't fire on
`str[..].as_bytes()`
So I ran into this in some codebase I was working on,
where the lint fired on this line:
```rust
let string: &str;
string[..].as_bytes()
```
So I was trying to understand the rationale behind this lint, and it
says:
> It involves doing an unnecessary UTF-8 alignment check which is less
efficient, and can cause a panic.
This is obviously not true in the case where a `RangeFull` slice is
being taken, since there is no UTF-8 boundary check, and no panic can be
caused. So I created an exemption for `RangeFull`s.
Two other notes:
1. I'm not sure the word "alignment" in the lint's description (quoted
above) is really correct, should probably say "char boundary" instead?
2. I might be missing something, but isn't there a lint for doing
superfluous slice indexing, and then calling a slice method? e.g.
`str[..].len()` or `slice[..].len()`, where `str` and `slice` are `&str`
and `&[T]`, respectively. If we had one, I would expect *it* to fire for
the example code I quoted above.
- move `is_allowed_vec_method` (a stripped-down version of it, anyway,
as the function doesn't make sense as is out of context) to utils, as
it's shared between `useless_vec` and `ptr_arg`
- add another test for non-standard macro brace case
- rm unneeded `allow`s
- rm duplicated tests
- add comments to some tests
cc @GuillaumeGomez
- Searching/filtering no longer creates a new history entry per
keystroke/change
- Loading a URL with a specified search query now works. The search is
now stored as `?search=foo` instead of `#/foo`, not a breaking change
since this didn't work before
- The browser back/forward actions now update the filters/search and
displayed lints
The bulk of the changes are to support that last one, previously the
filter state was stored both in the DOM and as JS objects. The DOM is
now the single source of truth
changelog: none
cc rust-lang/rust#148190 @flip1995 @RalfJung
This is a bit of a hack in that it hardcodes the list of crates with
stability attributes. This shouldn't be a big deal since that isn't a
set that changes very frequently and an internal lint could detect when
that happens.
The `fixme`s added aren't new issues and shouldn't get in the way of
unblocking the upstream issue.
changelog: none
Add new `function_casts_as_integer` lint
The `function_casts_as_integer` lint detects cases where users cast a function pointer into an integer.
*warn-by-default*
### Example
```rust
fn foo() {}
let x = foo as usize;
```
```
warning: casting a function into an integer implicitly
--> $DIR/function_casts_as_integer.rs:9:17
|
LL | let x = foo as usize;
| ^^^^^^^^
|
help: add `fn() as usize`
|
LL | let x = foo as fn() as usize;
| +++++++
```
### Explanation
You should never cast a function directly into an integer but go through a cast as `fn` first to make it obvious what's going on. It also allows to prevent confusion with (associated) constants.
Related to https://github.com/rust-lang/rust/issues/81686 and https://stackoverflow.com/questions/68701177/whats-the-meaning-of-casting-a-rust-enum-variant-to-a-numeric-data-type
r? ````@urgau````
Workspaces don't have their integration tests in tests/ at the root, so
this check missed them.
This fixesrust-lang/rust-clippy#11775 for workspaces.
changelog: [`mod_module_files`]: Fix false positive for integration
tests in workspace crates.
