| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This commit deletes the `alloc_system` crate from the standard
distribution. This unstable crate is no longer needed in the modern
stable global allocator world, but rather its functionality is folded
directly into the standard library. The standard library was already the
only stable location to access this crate, and as a result this should
not affect any stable code.
|
|
This commit removes all jemalloc related submodules, configuration, etc,
from the bootstrap, from the standard library, and from the compiler.
This will be followed up with a change to use jemalloc specifically as
part of rustc on blessed platforms.
|
|
* Also update the bootstrap compiler
* Update cargo to 1.32.0
* Clean out stage0 annotations
|
|
Fixes #55177
|
|
Fixes #47115
|
|
These work exactly like the normal chunks iterators but start creating
chunks from the end of the slice.
See #55177 for the tracking issue
|
|
|
|
|
|
See https://github.com/rust-lang/rust/issues/47115#issuecomment-403090815
and https://github.com/rust-lang/rust/issues/47115#issuecomment-424053547
|
|
Add trim_start, trim_end etc.; deprecate trim_left, trim_right, etc. in future
Adds the methods: `trim_start`, `trim_end`, `trim_start_matches` and `trim_end_matches`.
Deprecates `trim_left`, `trim_right`, `trim_left_matches` and `trim_right_matches` starting from Rust 1.33.0, three versions from when they'll initially be marked as being deprecated, using the future deprecation from https://github.com/rust-lang/rust/issues/30785 and https://github.com/rust-lang/rust/pull/51681.
Fixes https://github.com/rust-lang/rust/issues/30459.
|
|
|
|
|
|
|
|
|
|
Non-naive implementation of `VecDeque.append`
Replaces the old, simple implementation with a more manual (and **unsafe** 😱) one. I've added 1 more test and verified that it covers all 6 code paths in the function.
This new implementation was about 60% faster than the old naive one when I tried benchmarking it.
|
|
|
|
|
|
|
|
|
|
|
|
Incorporate a stray test
`liballoc/repeat-generic-slice.rs` doesn't seem to be tested (I think it was intended to be placed in `run-pass`). This PR incorporates the test into `liballoc/tests`.
|
|
|
|
|
|
|
|
Deprecation of str::slice_unchecked(_mut)
Closes #51715
I am not sure if 1.28.0 or 1.29.0 should be used for deprecation version, for now it's 1.28.0.
Additionally I've replaced `slice_unchecked` uses with `get_unchecked`. The only places where this method is still used are `src/liballoc/tests/str.rs` and `src/liballoc/tests/str.rs`.
|
|
|
|
|
|
|
|
Stabilize Iterator::step_by
Fixes #27741
|
|
Fixes #27741
|
|
|
|
old tests cover the new fast path of str joining already
this adds tests for joining into Strings with long separators (>4 byte) and
for joining into Vec<T>, T: Clone + !Copy. Vec<T: Copy> will be
specialised when specialisation type inference bugs are fixed.
|
|
Escape combining characters in char::Debug
Although combining characters are technically printable, they make little sense to print on their own with `Debug`: it'd be better to escape them like non-printable characters.
This is a breaking change, but I imagine the fact `escape_debug` is rare and almost certainly primarily used for debugging that this is an acceptable change.
Resolves #41922.
r? @alexcrichton
cc @clarcharr
|
|
|
|
|
|
|
|
|
|
Attempting to fix https://travis-ci.org/rust-lang/rust/jobs/377407894 via some
selective ignoring tests
|
|
Give SliceIndex impls a test suite of girth befitting the implementation (and fix a UTF8 boundary check)
So one day I was writing something in my codebase that basically amounted to `impl SliceIndex for (Bound<usize>, Bound<usize>)`, and I said to myself:
*Boy, gee, golly! I never realized bounds checking was so tricky!*
At some point when I had around 60 lines of tests for it, I decided to go see how the standard library does it to see if I missed any edge cases. ...That's when I discovered that libcore only had about 40 lines of tests for slicing altogether, and none of them even used `..=`.
---
This PR includes:
* **Literally the first appearance of the word `get_unchecked_mut` in any directory named `test` or `tests`.**
* Likewise the first appearance of `get_mut` used with _any type of range argument_ in these directories.
* Tests for the panics on overflow with `..=`.
* I wanted to test on `[(); usize::MAX]` as well but that takes linear time in debug mode </3
* A horrible and ugly test-generating macro for the `should_panic` tests that increases the DRYness by a single order of magnitude (which IMO wasn't enough, but I didn't want to go any further and risk making the tests inaccessible to next guy).
* Same stuff for str!
* Actually, the existing `str` tests were pretty good. I just helped filled in the holes.
* [A fix for the bug it caught](https://github.com/rust-lang/rust/issues/50002). (only one ~~sadly~~)
|
|
Introduce RangeInclusive::{new, start, end} methods and make the fields private.
cc #49022
|
|
|
|
Added new()/start()/end() methods to RangeInclusive.
Changed the lowering of `..=` to use RangeInclusive::new().
|
|
|
|
m*n lines of implementation deserves m*n lines of tests
|
|
GitHub users: I think you can add ?w=1 to the url
for a vastly cleaner whitespace-ignoring diff
|
|
This is in the matter of RFC 1940 and tracking issue #43302.
|
|
and add one for non-mut slicing since I touched that method too
|
|
|
|
Fixes #49608
|
|
|
