new lint: char_indices_as_byte_indices
#13435
Conversation
rustbot
added
the
S-waiting-on-review
| // 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 🤷♂️
There was a problem hiding this comment.
As said on Zulip, we could say that bytes should always be used as a replacement if it expects ASCII. I don't think there are any downsides to that. I think blocking compilation on those cases is better than not doing so for where it could actually be a problem.
|
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. |
y21
force-pushed
the
chars_enumerate_for_byte_index
branch
from
97c4bfb to
bf38bb1
Compare
|
☔ The latest upstream changes (presumably 1f966e9) made this pull request unmergeable. Please resolve the merge conflicts. |
| /// ``` | ||
| #[clippy::version = "1.83.0"] | ||
| pub CHARS_ENUMERATE_FOR_BYTE_INDICES, | ||
| correctness, |
There was a problem hiding this comment.
As said on Zulip, we could say that bytes should always be used as a replacement if it expects ASCII. I don't think there are any downsides to that. I think blocking compilation on those cases is better than not doing so for where it could actually be a problem.
y21
force-pushed
the
chars_enumerate_for_byte_index
branch
from
bf38bb1 to
4ac1ee8
Compare
|
Added a note for |
| "passing a character position to a method that expects a byte index" | ||
| }, | ||
| ExprKind::Index(target, ..) | ||
| if is_string_like(cx.typeck_results().expr_ty_adjusted(target).peel_refs()) |
There was a problem hiding this comment.
nit: I think the reason this isn't used in both arms is a bit non-obvious at first, especially if the comment on BYTE_INDEX_METHODS isn't seen. It could perhaps just point to what's already written there. That's about all.
|
Hey @y21, can you take a look at this again? Is there anything from my review that doesn't make sense/you're stuck on? |
|
Oops, I got busy and forgot about this. I'll look at this again over the weekend! |
y21
force-pushed
the
chars_enumerate_for_byte_index
branch
from
4ac1ee8 to
56124b8
Compare
y21
force-pushed
the
chars_enumerate_for_byte_index
branch
from
56124b8 to
c739027
Compare
y21
changed the title
chars_enumerate_for_byte_indiceschar_indices_as_byte_indices
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