new lint: chars_enumerate_for_byte_indices
#13435
Conversation
rustbot
added
the
S-waiting-on-review
| && cx.typeck_results().expr_ty_adjusted(recv).peel_refs().is_str() | ||
| && chars_segment.ident.name.as_str() == "chars" |
There was a problem hiding this comment.
Latest nightly has str::chars as a diagnostic item but our pinned nightly isn't there yet. Might be able to use that if the next sync happens soon enough
| // can't use #[expect] here because the .fixed file will still have the attribute and create an | ||
| // unfulfilled expectation, but make sure lint level attributes work on the use expression: | ||
| #[allow(clippy::chars_enumerate_for_byte_indices)] | ||
| let _ = prim[..idx]; |
There was a problem hiding this comment.
this is a fun one, I wonder if that's something that could be fixed in uitest, like removing #[expect] attributes in the .fixed file 🤔
| /// ``` | ||
| #[clippy::version = "1.83.0"] | ||
| pub CHARS_ENUMERATE_FOR_BYTE_INDICES, | ||
| correctness, |
There was a problem hiding this comment.
The pattern is technically fine if you know what your strings are (like the description mentions) so it's not always 'outright wrong' like the usual correctness lints, but the fix is also really simple and always applicable so 🤷♂️
|
Thank you for working on this. The linter we are working on (oxlint) has encountered dozens of crashes because of this, and there were no ways to forbid such usages. |
Closes #10202.
This adds a new lint that checks for uses of the
.chars().enumerate()position in a context where a byte index is required and suggests changing it to use.char_indices()instead.I'm planning to extend this lint to also detect uses of the position in iterator chains, e.g.
s.chars().enumerate().for_each(|(i, _)| s.split_at(i));, but that's for another timechangelog: new lint:
chars_enumerate_for_byte_indices