-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
str::char_at_reverse is broken #5956
Comments
This is actually the "correct" behaviour (at least it is the behaviour listed in the documentation of char_range_at_reverse). Also, note that Pull request #5957 hopefully corrects both of these issues. |
The documentation was unclear/wrong: it implies the functions operated on unicode char indices, but they actually operate on byte indices. Also, the `char_at_reverse` documentation was unclear whether it counted from the beginning or the end (causing #5956).
Closing, has been clarified in a documentation update. |
Re-enable len_zero for ranges now that `is_empty` is stable on them Fixes rust-lang#5956 Completed stabilization PR: rust-lang#75132 changelog: len_zero: re-enable linting ranges now that range_is_empty is stable
PR rust-lang#5956 started checking the stability of path segments. However, this was not applied to 'use tree' items (e.g. 'use some::path::{ItemOne, ItemTwo}') due to the way that we desugar these items in HIR lowering. This PR modifies 'use tree' lowering to preserve resolution information, which is needed by stability checking.
PR rust-lang#5956 started checking the stability of path segments. However, this was not applied to 'use tree' items (e.g. 'use some::path::{ItemOne, ItemTwo}') due to the way that we desugar these items in HIR lowering. This PR modifies 'use tree' lowering to preserve resolution information, which is needed by stability checking.
char_at_reverse(s, i) returns the character at i - 1 instead of s.char_len() - 1 - i.
The text was updated successfully, but these errors were encountered: