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 convert-from-bytes API cleanup #7039

Closed
wants to merge 9 commits into from

Conversation

erickt
Copy link
Contributor

@erickt erickt commented Jun 10, 2013

Good evening. This patch series cleans up the string API. str::from_bytes* was a bit of a mess. We had ways of taking a &[u8] and getting a ~str or &str, but no way to cheaply move a ~[u8] into a ~str. This patch series adds or changes to str:

fn from_bytes(v: ~[u8]) -> ~str;
fn from_bytes_with_null(v: ~[u8]) -> ~str;

fn from_bytes_slice<'a>(v: &'a [u8]) -> &'a str;
fn from_bytes_slice_with_null<'a>(v: &'a [u8]) -> &'a str;

and adds these to str::raw:

fn buf_len(buf: *u8) -> uint;

fn from_buf(buf: *u8) -> ~str;
fn from_buf_len(buf: *u8, len: uint) -> ~str;

fn buf_as_slice<T>(buf: *u8, f: &fn(&str) -> T) -> T;
fn buf_len_as_slice<T>(buf: *u8, len: uint, f: &fn(&str) -> T) -> T;

fn c_str_as_slice<T>(buf: *libc::c_char, f: &fn(&str) -> T) -> T;

And removes str_byte_slice and str_byte_slice_no_callback as those two functions are redundant. This fixes #7019.

@pcwalton
Copy link
Contributor

I'm not a big fan of the callback-based functions, personally. I'd rather just have buf_as_slice return &str, the rationale being that as it's an unsafe function, you could just as easily transmute the &str out of the closure.

@pcwalton
Copy link
Contributor

Oh, and what about having from_buf return &str? If the caller wants an ~str, he or she can just use .to_str() on the result…

@erickt erickt mentioned this pull request Jun 11, 2013
@graydon
Copy link
Contributor

graydon commented Jun 11, 2013

see also 967c7d8 and #3843

@huonw
Copy link
Member

huonw commented Jun 12, 2013

@erickt Sorry for stepping on your toes a bit with #7060, by the way.

@graydon graydon closed this Jun 13, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Apr 22, 2021
tabs_in_doc_comments: Fix ICE due to char indexing

This is a quick-fix for an ICE in `tabs_in_doc_comments`. The problem
was that we we're indexing into possibly multi-byte characters, such as '位'.

More specifically `get_chunks_of_tabs` was returning indices into
multi-byte characters. Those were passed on to a `Span` creation that
then caused the ICE.

This fix makes sure that we don't return indices that point inside a
multi-byte character. *However*, we are still iterating over unicode
codepoints, not grapheme clusters. So a seemingly single character like y̆ ,
which actually consists of two codepoints, will probably still cause
incorrect spans in the output. But I don't think we handle those cases
anywhere in Clippy currently?

Fixes rust-lang#5835

changelog: Fix ICE in `tabs_in_doc_comments`
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

Successfully merging this pull request may close these issues.

4 participants