about summary refs log tree commit diff
path: root/src/liballoc/tests
AgeCommit message (Collapse)AuthorLines
2020-02-22Auto merge of #67330 - golddranks:split_inclusive, r=kodrausbors-0/+124
Implement split_inclusive for slice and str # Overview * Implement `split_inclusive` for `slice` and `str` and `split_inclusive_mut` for `slice` * `split_inclusive` is a substring/subslice splitting iterator that includes the matched part in the iterated substrings as a terminator. * EDIT: The behaviour has now changed, as per @KodrAus 's input, to the same semantics with the `split_terminator` function. I updated the examples below. * Two examples below: ```Rust let data = "\nMäry häd ä little lämb\nLittle lämb\n"; let split: Vec<&str> = data.split_inclusive('\n').collect(); assert_eq!(split, ["\n", "Märy häd ä little lämb\n", "Little lämb\n"]); ``` ```Rust let uppercase_separated = "SheePSharKTurtlECaT"; let mut first_char = true; let split: Vec<&str> = uppercase_separated.split_inclusive(|c: char| { let split = !first_char && c.is_uppercase(); first_char = split; split }).collect(); assert_eq!(split, ["SheeP", "SharK", "TurtlE", "CaT"]); ``` # Justification for the API * I was surprised to find that stdlib currently only has splitting iterators that leave out the matched part. In my experience, wanting to leave a substring terminator as a part of the substring is a pretty common usecase. * This API is strictly more expressive than the standard `split` API: it's easy to get the behaviour of `split` by mapping a subslicing operation that drops the terminator. On the other hand it's impossible to derive this behaviour from `split` without using hacky and brittle `unsafe` code. The normal way to achieve this functionality would be implementing the iterator yourself. * Especially when dealing with mutable slices, the only way currently is to use `split_at_mut`. This API provides an ergonomic alternative that plays to the strengths of the iterating capabilities of Rust. (Using `split_at_mut` iteratively used to be a real pain before NLL, fortunately the situation is a bit better now.) # Discussion items * <s>Does it make sense to mimic `split_terminator` in that the final empty slice would be left off in case of the string/slice ending with a terminator? It might do, as this use case is naturally geared towards considering the matching part as a terminator instead of a separator.</s> * EDIT: The behaviour was changed to mimic `split_terminator`. * Does it make sense to have `split_inclusive_mut` for `&mut str`?
2020-02-16Lighten tests, in particular for Miri, yet test and explain moreStein Somers-20/+32
2020-02-09Rollup merge of #68738 - kennytm:derive-clone-eq-for-fromutf8error, r=sfacklerJonas Schievink-0/+4
Derive Clone + Eq for std::string::FromUtf8Error Implement `Clone` and `Eq` for `std::string::FromUtf8Error`. Both the inner `Vec<u8>` and `std::str::Utf8Error` are also `Clone + Eq`, so I don't see why we shouldn't derive them on `FromUtf8Error` as well. (impl are insta-stable, requiring FCP from T-libs.)
2020-02-09Don't return empty slice on last iteration with matched terminator. Test ↵Pyry Kontio-9/+94
reverse iteration.
2020-02-09Implement split_inclusive for slice and str, an splitting iterator that ↵Pyry Kontio-0/+39
includes the matched part in the iterated substrings as a terminator.
2020-02-04Fix and test implementation of BTreeMap's first_entry, last_entry, ↵Stein Somers-11/+21
pop_first, pop_last
2020-02-02Derive Clone + PartialEq + Eq for std::string::FromUtf8Errorkennytm-0/+4
2020-01-30Rollup merge of #66648 - crgl:btree-clone-from, r=AmanieuDylan DPC-0/+20
Implement clone_from for BTreeMap and BTreeSet See #28481. This results in up to 90% speedups on simple data types when `self` and `other` are the same size, and is generally comparable or faster. Some concerns: 1. This implementation requires an `Ord` bound on the `Clone` implementation for `BTreeMap` and `BTreeSet`. Since these structs can only be created externally for keys with `Ord` implemented, this should be fine? If not, there's certainly a less safe way to do this. 2. Changing `next_unchecked` on `RangeMut` to return mutable key references allows for replacing the entire overlapping portion of both maps without changing the external interface in any way. However, if `clone_from` fails it can leave the `BTreeMap` in an invalid state, which might be unacceptable. ~This probably needs an FCP since it changes a trait bound, but (as far as I know?) that change cannot break any external code.~
2020-01-28Include empty BTreeMap in clone_from testsCharles Gleason-2/+2
2020-01-27Rename `Alloc` to `AllocRef`Tim Diekmann-2/+2
2020-01-19FormatJonas Schievink-13/+9
2020-01-19Add test for panic in LL DrainFilter predicateJonas Schievink-0/+35
2020-01-19Avoid leak in DrainFilter when a drop panicsJonas Schievink-1/+35
2020-01-19Fix leak in vec::IntoIter when a destructor panicsJonas Schievink-0/+29
2020-01-19Fix leak in VecDeque::drain when drop panicsJonas Schievink-0/+38
2020-01-19Fix leak in btree_map::IntoIter when drop panicsJonas Schievink-0/+28
2020-01-19Avoid leak in `vec::Drain` when item drop panicsJonas Schievink-0/+39
2020-01-19Fix `VecDeque::truncate` leak on drop panicJonas Schievink-1/+34
2020-01-19Fix `binary_heap::DrainSorted` drop leak on panicsJonas Schievink-0/+33
2020-01-19Auto merge of #67758 - ssomers:testing_range, r=Mark-Simulacrumbors-31/+150
More thorough testing of BTreeMap::range Test more of the paths in the `range_search` function in map.rs
2020-01-11Revert "Rollup merge of #67727 - Dylan-DPC:stabilise/remove_item, ↵Lzu Tao-0/+1
r=alexcrichton" This reverts commit 4ed415b5478c74094c2859abfddb959588cd6bb1, reversing changes made to 3cce950743e8aa74a4378dfdefbbc80223a00865.
2020-01-06oh the one that was left behinddylan_DPC-1/+0
2020-01-05add feature gatedylan_DPC-0/+1
2020-01-04ef em ti ... :Pdylan_DPC-3/+3
2020-01-04add testsdylan_DPC-0/+15
2020-01-02Use drop instead of the toilet closure `|_| ()`Lzu Tao-2/+2
2019-12-31More thorough testing of BTreeMap::rangeStein Somers-31/+150
2019-12-26prune ill-conceived BTreeMap iter_mut assertion and test moreStein Somers-1/+122
2019-12-23Add test for BTreeMap::clone_fromCharles Gleason-0/+20
2019-12-22Format the worldMark Rousskov-514/+601
2019-12-13Rollup merge of #67235 - jonas-schievink:vecdeque-leak, r=KodrAusMazdak Farrokhzad-0/+34
VecDeque: drop remaining items on destructor panic Closes https://github.com/rust-lang/rust/issues/67232
2019-12-13Rollup merge of #67243 - jonas-schievink:linkedlist-drop, r=KodrAusMazdak Farrokhzad-0/+107
LinkedList: drop remaining items when drop panics https://github.com/rust-lang/rust/pull/67235, but for `LinkedList`, which has the same issue. I've also copied over the other drop-related tests from `VecDeque` since AFAICT `LinkedList` didn't have any.
2019-12-12LinkedList: drop remaining items when drop panicsJonas Schievink-0/+107
2019-12-11Small Cow improvementsAndre Bogus-0/+3
2019-12-11VecDeque: drop remaining items on destructor panicJonas Schievink-0/+34
2019-12-07liballoc: ignore tests in Miri instead of removing them entirelyRalf Jung-16/+15
2019-12-01Rollup merge of #66890 - dtolnay:fmt4, r=Dylan-DPCMazdak Farrokhzad-186/+144
Format liballoc with rustfmt Same strategy as #66691 -- as with my previous formatting PRs, I am avoiding causing merge conflicts in other PRs by only touches those files that are not involved in any currently open PR. Files that appear in new PRs between when this PR is opened and when it makes it to the top of the bors queue will be reverted from this PR. The list of files involved in open PRs is determined by querying GitHub's GraphQL API [with this script](https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8). With the list of files from the script in outstanding_files, the relevant commands were: ``` $ find src/liballoc -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg liballoc outstanding_files | xargs git checkout -- ``` To confirm no funny business: ``` $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference ``` r? @Dylan-DPC
2019-12-01Rollup merge of #66662 - RalfJung:miri-test-liballoc, r=dtolnayMazdak Farrokhzad-14/+24
Miri: run panic-catching tests in liballoc I also converted two tests from using `thread::spawn(...).join()` just for catching panics, to `catch_panic`, so that Miri can run them.
2019-11-29Format liballoc with rustfmtDavid Tolnay-186/+144
2019-11-26Fix spelling typosBrian Wignall-1/+1
2019-11-23enable more panic-catching tests in MiriRalf Jung-4/+15
2019-11-22enable panic-catching tests in MiriRalf Jung-3/+6
2019-11-22use catch_panic instead of thread::spawn to catch panicsRalf Jung-8/+5
2019-11-22enable panic-catching tests in MiriRalf Jung-4/+3
2019-11-13Auto merge of #65637 - ssomers:master, r=scottmcmbors-0/+74
proposal for BTreeMap/Set min/max, #62924 - Which pair of names: #62924 lists the existing possibilities min/max, first/last, (EDIT) front/back, peek(/peek_back?). Iterators have next/next_back or next/last. I'm slightly in favour of first/last because min/max might suggest they search over the entire map, and front/back pretends they are only about position. - Return key only instead of pair like iterator does? - If not, then keep the _key_value suffix? ~~Also provide variant with mutable value? But there is no such variant for get_key_value.~~ - Look for and upgrade more usages of `.iter().next()` and such in the libraries? I only upgraded the ones I contributed myself, all very recently.
2019-10-31Auto merge of #65091 - sekineh:into-iter-sorted, r=KodrAusbors-4/+75
Implement ordered/sorted iterators on BinaryHeap as per #59278 I've implemented the ordered version of iterator on BinaryHeap as per #59278. # Added methods: * `.into_iter_sorted()` * like `.into_iter()`; but returns elements in heap order * `.drain_sorted()` * like `.drain()`; but returns elements in heap order * It's a bit _lazy_; elements are removed on drop. (Edit: it’s similar to vec::Drain) For `DrainSorted` struct, I implemented `Drop` trait following @scottmcm 's [suggestion](https://github.com/rust-lang/rust/issues/59278#issuecomment-537306925) # ~TODO~ DONE * ~I think I need to add more tests other than doctest.~ # **Notes:** * we renamed `_ordered` to `_sorted`, because the latter is more common in rust libs. (as suggested by @KodrAus )
2019-10-28Rollup merge of #64747 - ethanboxx:master, r=CentrilMazdak Farrokhzad-1/+0
Stabilize `Option::flatten` - PR: https://github.com/rust-lang/rust/pull/60256 - Tracking issue: https://github.com/rust-lang/rust/issues/60258 @elahn > I was trying to `flat_map()` and found `map().flatten()` does the trick. This has been on nightly for 4 months, can we stabilise it? @ethanboxx > @Centril Helped me get this merged. What is the stabilization process? @Centril > @ethanboxx I'd just file a PR to stabilize it and we'll ask T-libs to FCP. So here I am. I am was unsure what number to put in `since = "-"` so I copied what someone had done in a recent PR.
2019-10-25Remove unused `use`s.Hideki Sekine-4/+0
2019-10-25Add .into_iter_sorted() and .drain_sorted()Hideki Sekine-4/+79
* `.drain_sorted()` doc change suggested by @KodrAus
2019-10-23proposal for access to BTreeMap/BTreeSet first/last, #62924Stein Somers-0/+74
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-14 17:32:06 +0000