| Age | Commit message (Collapse) | Author | Lines |
|---|
|
The previous docstring was copied from dedup_by_key.
|
|
Now it always implies right-alignment, so that padding zeroes are placed after the sign (if any) and before the digits. In other words, it always takes precedence over explicitly specified `[[fill]align]`. This also affects the '#' flag: zeroes are placed after the prefix (0b, 0o, 0x) and before the digits.
:05 :<05 :>05 :^05
before |-0001| |-1000| |-0001| |-0100|
after |-0001| |-0001| |-0001| |-0001|
:#05x :<#05x :>#05x :^#05x
before |0x001| |0x100| |000x1| |0x010|
after |0x001| |0x001| |0x001| |0x001|
Fixes #39997 [breaking-change]
|
|
Leftovers from #39594; From<Box> impls
These are a few more impls that follow the same reasoning as those from #39594.
What's included:
* `From<Box<str>> for String`
* `From<Box<[T]>> for Vec<T>`
* `From<Box<CStr>> for CString`
* `From<Box<OsStr>> for OsString`
* `From<Box<Path>> for PathBuf`
* `Into<Box<str>> for String`
* `Into<Box<[T]>> for Vec<T>`
* `Into<Box<CStr>> for CString`
* `Into<Box<OsStr>> for OsString`
* `Into<Box<Path>> for PathBuf`
* `<Box<CStr>>::into_c_string`
* `<Box<OsStr>>::into_os_string`
* `<Box<Path>>::into_path_buf`
* Tracking issue for latter three methods + three from previous PR.
Currently, the opposite direction isn't doable with `From` (only `Into`) because of the separation between `liballoc` and `libcollections`. I'm holding off on those for a later PR.
|
|
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
|
|
|
|
Clarify docs in `VecDeque::resize`
|
|
Implement placement-in protocol for `VecDeque`
CC #30172
r? @nagisa
|
|
|
|
|
|
|
|
Document why `str.to_{lower,upper}case` return `String`
Fixes #39201.
|
|
Added remove_from to vec.rs (#38143)
Turns out that if you push to someone's PR branch and cause the PR to close, you lose delegation š.
@madseagames I'm really sorry about that š
|
|
Fixes #39201.
|
|
|
|
|
|
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
|
|
impl RangeArgument for RangeInclusive and add appropriate tests
Now that `RangeArgument` returns a `Bound`, the impl for `RangeInclusive` is natural to implement and all that's required are tests around it.
|
|
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.
|
|
Update std::fmt module docs for landing of #33642.
Since #33642, it's no longer true that all references to a given format argument must use the same type. The docs don't seem to have been updated.
|
|
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`.
|
|
|
|
fix types in to_owned doctest
Fixes #39831.
|
|
Dont segfault if btree range is not in order
This is a first attempt to fix issue #33197. The issue is that the BTree iterator uses next_unchecked for fast iteration, but it can be tricked into running off the end of the tree and segfaulting if range is called with a maximum that is less than the minimum.
Since a user defined Ord should not determine the safety of BTreeMap, and we still want fast iteration, I've implemented the idea of @gereeter and walk the tree simultaneously searching for both keys to make sure that if our keys diverge, the min key is to the left of our max key. I currently panic if that is not the case.
Open questions:
1. Do we want to panic in this error case or do we want to return an empty iterator? The drain API panics if the range is bad, but drain is given a range of index values, while this is a generic key type. Panicking is brittle and returning an empty iterator is probably the most flexible and matches what people would want it to do... but artificially returning a BTreeMap::Range with start==end seems like a pretty weird and unnatural thing to do, although it's doable since those fields are not accessible.
The same question for other weird cases:
2. (Included(101), Excluded(100)) on a map that contains [1,2,3]. Both BTree edges end up on the same part of the map, but comparing the keys shows the range is backwards.
3. (Excluded(5), Excluded(5)). The keys are equal but BTree edges end up backwards if the map contains 5.
4. (Included(5), Excluded(5)). Should naturally produce an empty iterator, right?
|
|
|
|
|
|
|
|
Explicitly mention that `Vec::reserve` is based on len not capacity
I spent a good chunk of time tracking down a buffer overrun bug that
resulted from me mistakenly thinking that `reserve` was based on the
current capacity not the current length. It would be helpful if this
were called out explicitly in the docs.
|
|
|
|
Reminding people of set terminology.
|
|
I spent a good chunk of time tracking down a buffer overrun bug that
resulted from me mistakenly thinking that `reserve` was based on the
current capacity not the current length. It would be helpful if this
were called out explicitly in the docs.
|
|
Extract collections benchmarks to libcollections/bench
Good suggestion from @stjepang https://github.com/rust-lang/rust/issues/39484#issuecomment-277467765
r? @alexcrichton
|
|
Add Debug implementations for libcollection structs
Part of #31869.
|
|
And libcore/benches
|
|
Slightly optimize slice::sort
First, get rid of some bound checks.
Second, instead of comparing by ternary `compare` function, use a binary function testing whether an element is less than some other element. This apparently makes it easier for the compiler to reason about the code. I've noticed the same effect with [pdqsort](https://github.com/stjepang/pdqsort) crate.
Benchmark:
```
name before ns/iter after ns/iter diff ns/iter diff %
slice::bench::sort_large_ascending 8,969 (8919 MB/s) 7,410 (10796 MB/s) -1,559 -17.38%
slice::bench::sort_large_big_ascending 355,640 (3599 MB/s) 359,137 (3564 MB/s) 3,497 0.98%
slice::bench::sort_large_big_descending 427,112 (2996 MB/s) 424,721 (3013 MB/s) -2,391 -0.56%
slice::bench::sort_large_big_random 2,207,799 (579 MB/s) 2,138,804 (598 MB/s) -68,995 -3.13%
slice::bench::sort_large_descending 13,694 (5841 MB/s) 13,514 (5919 MB/s) -180 -1.31%
slice::bench::sort_large_mostly_ascending 239,697 (333 MB/s) 203,542 (393 MB/s) -36,155 -15.08%
slice::bench::sort_large_mostly_descending 270,102 (296 MB/s) 234,263 (341 MB/s) -35,839 -13.27%
slice::bench::sort_large_random 513,406 (155 MB/s) 470,084 (170 MB/s) -43,322 -8.44%
slice::bench::sort_large_random_expensive 23,650,321 (3 MB/s) 23,675,098 (3 MB/s) 24,777 0.10%
slice::bench::sort_medium_ascending 143 (5594 MB/s) 132 (6060 MB/s) -11 -7.69%
slice::bench::sort_medium_descending 197 (4060 MB/s) 188 (4255 MB/s) -9 -4.57%
slice::bench::sort_medium_random 3,358 (238 MB/s) 3,271 (244 MB/s) -87 -2.59%
slice::bench::sort_small_ascending 32 (2500 MB/s) 32 (2500 MB/s) 0 0.00%
slice::bench::sort_small_big_ascending 97 (13195 MB/s) 97 (13195 MB/s) 0 0.00%
slice::bench::sort_small_big_descending 247 (5182 MB/s) 249 (5140 MB/s) 2 0.81%
slice::bench::sort_small_big_random 502 (2549 MB/s) 498 (2570 MB/s) -4 -0.80%
slice::bench::sort_small_descending 55 (1454 MB/s) 61 (1311 MB/s) 6 10.91%
slice::bench::sort_small_random 358 (223 MB/s) 356 (224 MB/s) -2 -0.56%
```
|
|
Fix a few impl stability attributes
The versions show up in rustdoc.
|
|
|
|
First, get rid of some bound checks.
Second, instead of comparing by ternary `compare` function, use a binary
function testing whether an element is less than some other element.
This apparently makes it easier for the compiler to reason about the
code.
Benchmark:
```
name before ns/iter after ns/iter diff ns/iter diff %
slice::bench::sort_large_ascending 8,969 (8919 MB/s) 7,410 (10796 MB/s) -1,559 -17.38%
slice::bench::sort_large_big_ascending 355,640 (3599 MB/s) 359,137 (3564 MB/s) 3,497 0.98%
slice::bench::sort_large_big_descending 427,112 (2996 MB/s) 424,721 (3013 MB/s) -2,391 -0.56%
slice::bench::sort_large_big_random 2,207,799 (579 MB/s) 2,138,804 (598 MB/s) -68,995 -3.13%
slice::bench::sort_large_descending 13,694 (5841 MB/s) 13,514 (5919 MB/s) -180 -1.31%
slice::bench::sort_large_mostly_ascending 239,697 (333 MB/s) 203,542 (393 MB/s) -36,155 -15.08%
slice::bench::sort_large_mostly_descending 270,102 (296 MB/s) 234,263 (341 MB/s) -35,839 -13.27%
slice::bench::sort_large_random 513,406 (155 MB/s) 470,084 (170 MB/s) -43,322 -8.44%
slice::bench::sort_large_random_expensive 23,650,321 (3 MB/s) 23,675,098 (3 MB/s) 24,777 0.10%
slice::bench::sort_medium_ascending 143 (5594 MB/s) 132 (6060 MB/s) -11 -7.69%
slice::bench::sort_medium_descending 197 (4060 MB/s) 188 (4255 MB/s) -9 -4.57%
slice::bench::sort_medium_random 3,358 (238 MB/s) 3,271 (244 MB/s) -87 -2.59%
slice::bench::sort_small_ascending 32 (2500 MB/s) 32 (2500 MB/s) 0 0.00%
slice::bench::sort_small_big_ascending 97 (13195 MB/s) 97 (13195 MB/s) 0 0.00%
slice::bench::sort_small_big_descending 247 (5182 MB/s) 249 (5140 MB/s) 2 0.81%
slice::bench::sort_small_big_random 502 (2549 MB/s) 498 (2570 MB/s) -4 -0.80%
slice::bench::sort_small_descending 55 (1454 MB/s) 61 (1311 MB/s) 6 10.91%
slice::bench::sort_small_random 358 (223 MB/s) 356 (224 MB/s) -2 -0.56%
```
|
|
std: Add ToString trait specialization for Cow<'a, str> and String
There is a specialized version of ToString for str type in std. I think there are other types can also benefit from specialization. `Cow` and `String` are the most obvious one.
r? @bluss
|
|
|
|
std: Fix IntoIter::as_mut_slice's signature
This was intended to require `&mut self`, not `&self`, otherwise it's unsound!
Closes #39465
|
|
This was intended to require `&mut self`, not `&self`, otherwise it's unsound!
Closes #39465
|
