Deprecated/moved functions in collections::str

[aochagavia]

• Deprecated str::from_utf8_owned in favor of String::from_utf8
• Deprecated str::from_utf8_lossy in favor of String::from_utf8_lossy
• Deprecated str::from_utf16 in favor of String::from_utf16
• Deprecated str::from_utf16_lossy in favor of String::from_utf16_lossy
• Deprecated str::from_chars in favor of String::from_chars
• Deprecated str::from_char in favor of String::from_char and .to_string()
• Deprecated str::from_byte in favor of String::from_byte

[breaking-change]

[aochagavia]

And it finaly passes the Travis build!

[alexcrichton]

This is changing a core standard library modules, so it should be discussed a bit before merging.

I'm in favor of all changes made here.

cc @aturon

[aochagavia]

Are there any news on this? Should I rebase it?

[aturon]

@aochagavia Sorry about the delay. This is my fault -- the CC from Alex got lost in my inbox!

I am definitely in favor of this change. I would also like to see the from_utf16, from_utf16_lossy and from_utf8_lossy functions move to string.

The MaybeOwned type is a split personality between String and &str, so from_utf8_lossy can reasonably live in either module -- but I would argue it should live in string so that all of these related functions are available from a single spot.

[alexcrichton]

Looks like this needs a rebase, but r=me with a rebase.

[aochagavia]

Done 😉!

[aochagavia]

This should now be fixed.

[aochagavia]

I have also fixed that one... No idea why it hasn't been catched by the Travis build...

[alexcrichton]

The travis builds only exercise functionality on linux, and the bugs have been on windows/osx so these are likely platform-specific modules.

[aochagavia]

I could fix this by using transmute, but it looks very hacky... Is there a better alternative?

[alexcrichton]

For the collections tests I would recommend ensuring that the right instance of Vec is imported for the tests. Also, could you be sure to run the entire test suite locally before asking for another r+? Refactorings like this often lead to tricky-to-find bugs.

[aochagavia]

I have compiled and tested the collections library with rustc lib.rs --test. All tests pass now.

[alexcrichton]

Just to be sure, have you run a full make check? There are many surprises other than just libcollections!

[aochagavia]

Yes I have, most test pass but I got a strange error when running bootstrap-from-c-with-green. I think it isn't related to the changes I made though:

/c/Users/aochagavia/Desktop/rust/i686-pc-mingw32/test/run-make/bootstrap-from-c-with-green/main.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory make[1]: *** [all] Error 127

[alexcrichton]

Errors like that are normally benign, so let's give this another go

[alexcrichton]

Thanks again of course!

[aochagavia]

No problem! I am the one who benefits most from this 😉! I am really learning a lot here.

[aochagavia]

Sorry, I forgot to update some of the code examples of the deprecated functions (make check didn't catch it because it failed before testing the docs). Now I have replaced them by a comment saying that the function is deprecated, and pointing to the methods defined in String.

[aochagavia]

I am sorry it failed again... There were some encoding issues in the code examples (I accidentaly copied some UTF-8 text and pasted it as ASCII), so the assertions failed. It should be ok now.

I tried to test this before pushing, but it is really a pain to do since I am on Windows. The tests fail before reaching the code examples of collections.

[alexcrichton]

Awesome \o/