| Age | Commit message (Collapse) | Author | Lines |
|
|
|
These were found by running tidy on stable versions of rust and finding
features stabilised with the wrong version numbers.
|
|
|
|
More methods for str boxes. (reduce Box<[u8]> ↔ Box<str> transmutes)
This is a follow-up to #41096 that adds safer methods for converting between `Box<str>` and `Box<[u8]>`. They're gated under a different feature from the `&mut str` methods because they may be too niche to include in public APIs, although having them internally helps reduce the number of transmutes the standard library uses.
What's added:
* `From<Box<str>> for Box<[u8]>`
* `<Box<str>>::into_boxed_bytes` (just calls `Into::into`)
* `alloc::str` (new module)
* `from_boxed_utf8` and `from_boxed_utf8_unchecked`, defined in `alloc:str`, exported in `collections::str`
* exports `from_utf8_mut` in `collections::str` (missed from previous PR)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This change allows to obtain an underlying invalid UTF-8 bytes
without `FromUtf8Error` destruction. Such method may be useful
for example in a library that attempts to save both valid and
invalid UTF-8 strings in some struct and to be able to provide
immutable access to it without destruction.
|
|
|
|
r=GuillaumeGomez
Remove function invokation parens from documentation links.
This was never established as a convention we should follow in the 'More
API Documentation Conventions' RFC:
https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md
|
|
This was never established as a convention we should follow in the 'More
API Documentation Conventions' RFC:
https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md
|
|
|
|
|
|
Reduce std_unicode’s public API
* Only keep one copy of the `UTF8_CHAR_WIDTH` table instead of one of each of libcore and libstd_unicode.
* Move the `utf8_char_width` function to `core::str` under the `str_internals` unstable feature.
* Remove `std_unicode::str::is_utf16`. It was only accessible through the `#[unstable]` crate std_unicode. It has never been used in the compiler or standard library since 47e7a05 added it in 2012 “for OS API interop”. It can be replaced with a one-liner:
```rust
fn is_utf16(slice: &[u16]) -> bool {
std::char::decode_utf16(s).all(|r| r.is_ok())
}
```
|
|
Panic on errors in `format!` or `<T: Display>::to_string`
… instead of silently ignoring a result.
`fmt::Write for String` never returns `Err`, so implementations of `Display` (or other traits of that family) never should either.
Fixes #40103
|
|
… instead of silently ignoring a result.
`fmt::Write for String` never returns `Err`,
so implementations of `Display` (or other traits of that family)
never should either.
Fixes #40103
|
|
… instead of one of each of libcore and libstd_unicode.
Move the `utf8_char_width` function to `core::str`
under the `str_internals` unstable feature.
|
|
impl FromIterator<&char> for String
|
|
Add notes about capacity effects to Vec::truncate()
Add notes about the effects of Vec::truncate() and Vec::clear() on the capacity of a vector.
|
|
Additional docs for Vec, String, and slice trait impls
r? @steveklabnik
|
|
|
|
1. Clarify that `String::split_off` returns one string and modifies self
in-place. The documentation implied that it returns two new strings.
2. Make the documentation mirror `Vec::split_off`.
|
|
|
|
|
|
Add Debug implementations for libcollection structs
Part of #31869.
|
|
|
|
r? @bluss
|
|
This commit applies the stabilization/deprecations of the 1.16.0 release, as
tracked by the rust-lang/rust issue tracker and the final-comment-period tag.
The following APIs were stabilized:
* `VecDeque::truncate`
* `VecDeque::resize`
* `String::insert_str`
* `Duration::checked_{add,sub,div,mul}`
* `str::replacen`
* `SocketAddr::is_ipv{4,6}`
* `IpAddr::is_ipv{4,6}`
* `str::repeat`
* `Vec::dedup_by`
* `Vec::dedup_by_key`
* `Result::unwrap_or_default`
* `<*const T>::wrapping_offset`
* `<*mut T>::wrapping_offset`
* `CommandExt::creation_flags` (on Windows)
* `File::set_permissions`
* `String::split_off`
The following APIs were deprecated
* `EnumSet` - replaced with other ecosystem abstractions, long since unstable
Closes #27788
Closes #35553
Closes #35774
Closes #36436
Closes #36949
Closes #37079
Closes #37087
Closes #37516
Closes #37827
Closes #37916
Closes #37966
Closes #38080
|
|
|
|
|
|
|
|
Rename 'librustc_unicode' crate to 'libstd_unicode'.
Fixes https://github.com/rust-lang/rust/issues/26554.
|
|
|
|
|
|
Fixes #26554.
|
|
|
|
`as_bytes` is not the iterator on String, `bytes` is
r? @steveklabnik
|
|
|
|
Motivation: the `selectors` crate is generic over a string type,
in order to support all of `String`, `string_cache::Atom`, and
`gecko_string_cache::Atom`. Multiple trait bounds are used
for the various operations done with these strings.
One of these operations is creating a string (as efficiently as possible,
re-using an existing memory allocation if possible) from `Cow<str>`.
The `std::convert::From` trait seems natural for this, but
the relevant implementation was missing before this PR.
To work around this I’ve added a `FromCowStr` trait in `selectors`,
but with trait coherence that means one of `selectors` or `string_cache`
needs to depend on the other to implement this trait.
Using a trait from `std` would solve this.
The `Vec<T>` implementation is just added for consistency.
I also tried a more general
`impl<'a, O, B: ?Sized + ToOwned<Owned=O>> From<Cow<'a, B>> for O`,
but (the compiler thinks?) it conflicts with `From<T> for T` the impl
(after moving all of `collections::borrow` into `core::borrow`
to work around trait coherence).
|
|
|
|
Fix some typos and improve doc comments style
r? @steveklabnik
|
|
return a slice
They panic if the buffer is too small.
|
|
|
|
This reverts commit ac73335f2f5421c914fa3900567696cc6dc73d8d.
|
|
|
|
Implement 1581 (FusedIterator)
* [ ] Implement on patterns. See https://github.com/rust-lang/rust/issues/27721#issuecomment-239638642.
* [ ] Handle OS Iterators. A bunch of iterators (`Args`, `Env`, etc.) in libstd wrap platform specific iterators. The current ones all appear to be well-behaved but can we assume that future ones will be?
* [ ] Does someone want to audit this? On first glance, all of the iterators on which I implemented `FusedIterator` appear to be well-behaved but there are a *lot* of them so a second pair of eyes would be nice.
* I haven't touched rustc internal iterators (or the internal rand) because rustc doesn't actually call `fuse()`.
* `FusedIterator` can't be implemented on `std::io::{Bytes, Chars}`.
Closes: #35602 (Tracking Issue)
Implements: rust-lang/rfcs#1581
|