| Age | Commit message (Collapse) | Author | Lines |
|
`unboxed_closures`
They are already gated with feature `fn_traits`
|
|
|
|
Rewrite `collections::LinkedList::append` doc example.
None
|
|
More intuitive explantion of strings formatting
|
|
|
|
Escape fewer Unicode codepoints in `Debug` impl of `str`
Use the same procedure as Python to determine whether a character is
printable, described in [PEP 3138]. In particular, this means that the
following character classes are escaped:
- Cc (Other, Control)
- Cf (Other, Format)
- Cs (Other, Surrogate), even though they can't appear in Rust strings
- Co (Other, Private Use)
- Cn (Other, Not Assigned)
- Zl (Separator, Line)
- Zp (Separator, Paragraph)
- Zs (Separator, Space), except for the ASCII space `' '` `0x20`
This allows for user-friendly inspection of strings that are not
English (e.g. compare `"\u{e9}\u{e8}\u{ea}"` to `"éèê"`).
Fixes #34318.
CC #34422.
[PEP 3138]: https://www.python.org/dev/peps/pep-3138/
|
|
Make vec::Drain and binary_heap::Drain covariant
I removed all mutable pointers/references, and added covariance tests similar to the ones in #32635. It builds and passes the tests, but I noticed that there weren't any tests of Drain's behaviour (at least not in libcollectionstest), so I'm not sure if my changes accidently broke Drain's behaviour. Should I add some tests for that (and if so, what should the tests include)?
|
|
|
|
Though there are ways to convert a slice or vec of chars into a string,
it would be nice to be able to just do `String::from(['a', 'b', 'c'])`,
so this PR implements `From<Vec<char>>` and `From<&'a [char]>` for
String.
|
|
Rewrite/expansion of `slice::split` doc examples.
None
|
|
Update VecDeque documentation to specify direction of index 0 (#34920)
I mentioned the direction for all the methods that work with an index
|
|
|
|
|
|
|
|
Fix incorrect 'memory leak' example for `Vec::set_len`.
Example was written in https://github.com/rust-lang/rust/pull/34911
Issue was brought up in this comment:
https://github.com/rust-lang/rust/commit/a005b2cd2ac679da7393e537aa05e2b7d32d36d5#commitcomment-18346958
|
|
Doc example improvements for `slice::windows`.
* Modify existing example to not rely on printing to see results
* Add an example demonstrating when slice is shorter than `size`
|
|
* Modify existing example to not rely on printing to see results
* Add an example demonstrating when slice is shorter than `size`
|
|
Example was written in https://github.com/rust-lang/rust/pull/34911
Issue was brought up in this comment:
https://github.com/rust-lang/rust/commit/a005b2cd2ac679da7393e537aa05e2b7d32d36d5#commitcomment-18346958
|
|
|
|
Add method `String::insert_str`
|
|
|
|
3Hren:issue/xx/reinterpret-format-precision-for-strings, r=alexcrichton
feat: reinterpret `precision` field for strings
This commit changes the behavior of formatting string arguments with both width and precision fields set.
Documentation says that the `width` field is the "minimum width" that the format should take up. If the value's string does not fill up this many characters, then the padding specified by fill/alignment will be used to take up the required space.
This is true for all formatted types except string, which is truncated down to `precision` number of chars and then all of `fill`, `align` and `width` fields are completely ignored.
For example: `format!("{:/^10.8}", "1234567890);` emits "12345678". In the contrast Python version works as the expected:
```python
>>> '{:/^10.8}'.format('1234567890')
'/12345678/'
```
This commit gives back the `Python` behavior by changing the `precision` field meaning to the truncation and nothing more. The result string *will* be prepended/appended up to the `width` field with the proper `fill` char.
__However, this is the breaking change, I admit.__ Feel free to close it, but otherwise it should be mentioned in the `std::fmt` documentation somewhere near of `fill/align/width` fields description.
|
|
Add doc examples for `Vec::{as_slice,as_mut_slice}`.
None
|
|
Add doc for btree_map types
Part of #29348.
r? @steveklabnik
|
|
Rewrite/expand doc examples for `Vec::set_len`.
None
|
|
implement AddAssign for String
Currently `String` implements `Add` but not `AddAssign`. This PR fills in that gap.
I played around with having `AddAssign` (and `Add` and `push_str`) take `AsRef<str>` instead of `&str`, but it looks like that breaks arguments that implement `Deref<Target=str>` and not `AsRef<str>`. Comments in [`libcore/convert.rs`](https://github.com/rust-lang/rust/blob/master/src/libcore/convert.rs#L207-L213) make it sound like we could fix this with a blanket impl eventually. Does anyone know what's blocking that?
|
|
Add examples for VecDeque
Part of #29348.
r? @steveklabnik
|
|
Add examples for LinkedList
Part of #29348.
r? @steveklabnik
|
|
|
|
|
|
|
|
Add debug for btree_map::{Entry, VacantEntry, OccupiedEntry}
|
|
|
|
|
|
|
|
|
|
Improve {String,Vec}::from_raw_parts documentation
|
|
Partial rewrite/expansion of `Vec::truncate` documentation.
None
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Replace `LinkedList`'s use of `Box` with `Shared`
Closes #34417
|
|
|
|
Improve slice docs
Fixes #29337.
r? @steveklabnik
|
|
make docs for clone_from_slice consistent with copy_from_slice
What 'this slice' refers to is not intuitive, given this method can appear in other places, e.g. in docs for Vec.
|