Skip to content
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

Closed
ahnurmi opened this issue Apr 19, 2013 · 2 comments
Closed

str::char_at_reverse is broken #5956

ahnurmi opened this issue Apr 19, 2013 · 2 comments

Comments

@ahnurmi
Copy link

ahnurmi commented Apr 19, 2013

char_at_reverse(s, i) returns the character at i - 1 instead of s.char_len() - 1 - i.

@huonw
Copy link
Member

huonw commented Apr 19, 2013

This is actually the "correct" behaviour (at least it is the behaviour listed in the documentation of char_range_at_reverse). Also, note that char_at and char_at_reverse actually deal with byte positions, not unicode char positions (this is not stated in the documentation for either of these :( ).

Pull request #5957 hopefully corrects both of these issues.

bors added a commit that referenced this issue Apr 19, 2013
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).
@z0w0
Copy link
Contributor

z0w0 commented Jun 6, 2013

Closing, has been clarified in a documentation update.

@z0w0 z0w0 closed this as completed Jun 6, 2013
flip1995 pushed a commit to flip1995/rust that referenced this issue Aug 28, 2020
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
Aaron1011 added a commit to Aaron1011/rust that referenced this issue Jul 15, 2022
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.
lyming2007 pushed a commit to lyming2007/rust that referenced this issue Oct 21, 2022
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants