about summary refs log tree commit diff
path: root/src/libcore/slice/mod.rs
AgeCommit message (Collapse)AuthorLines
2020-07-27mv std libs to library/mark-6453/+0
2020-07-25Auto merge of #74510 - LukasKalbertodt:fix-range-from-index-panic, ↵bors-6/+19
r=hanna-kruppe Fix panic message when `RangeFrom` index is out of bounds Before, the `Range` method was called with `end = slice.len()`. Unfortunately, because `Range::index` first checks the order of the indices (start has to be smaller than end), an out of bounds index leads to `core::slice::slice_index_order_fail` being called. This prints the message 'slice index starts at 27 but ends at 10', which is worse than 'index 27 out of range for slice of length 10'. This is not only useful to normal users reading panic messages, but also for people inspecting assembly and being confused by `slice_index_order_fail` calls. You can see the produced assembly [here](https://rust.godbolt.org/z/GzMGWf) and try on Playground [here](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=aada5996b2f3848075a6d02cf4055743). (By the way. this is only about which panic function is called; I'm pretty sure it does not improve anything about performance).
2020-07-20Auto merge of #74010 - pierwill:pierwill-o-notation, r=GuillaumeGomezbors-7/+7
Use italics for O notation In documentation, I think it makes sense to italicize O notation (*O(n)*) as opposed to using back-ticks (`O(n)`). Visually, back-ticks focus the reader on the literal characters being used, making them ideal for representing code. Using italics, as far I can tell, more closely follows typographic conventions in mathematics and computer science. Just a suggestion, of course! 😇
2020-07-19Use italics for O notationpierwill-7/+7
Co-authored-by: Guillaume Gomez <guillaume1.gomez@gmail.com>
2020-07-20Slightly improve panic messages when range indices are out of boundsLukas Kalbertodt-6/+13
2020-07-19Fix panic message when `RangeFrom` index is out of boundsLukas Kalbertodt-2/+8
Before, the `Range` method was called with `end = slice.len()`. Unfortunately, because `Range::index` first checks the order of the indices (start has to be smaller than end), an out of bounds index leads to `core::slice::slice_index_order_fail` being called. This prints the message 'slice index starts at 27 but ends at 10', which is worse than 'index 27 out of range for slice of length 10'. This is not only useful to normal users reading panic messages, but also for people inspecting assembly and being confused by `slice_index_order_fail` calls.
2020-07-17Fix `Safety` docs for `from_raw_parts_mut`aticu-1/+1
2020-07-16apply bootstrap cfgsMark Rousskov-12/+0
2020-07-14Rollup merge of #73986 - RalfJung:raw-slice-as-ptr, r=sfacklerManish Goregaokar-52/+59
add (unchecked) indexing methods to raw (and NonNull) slices This complements the existing (unstable) `len` method. Unfortunately, for non-null slices, we cannot call this method `as_ptr` as that overlaps with the existing method of the same name. If this looks reasonable to accept, I propose to reuse the https://github.com/rust-lang/rust/issues/71146 tracking issue and rename the feature get to `slice_ptr_methods` or so. Cc @SimonSapin Fixes https://github.com/rust-lang/rust/issues/60639
2020-07-05Optimize is_ascii for &str and &[u8]Thom Chiovoloni-1/+101
2020-07-05make unchecked slice indexing helper methods use raw pointersRalf Jung-52/+59
2020-07-02Rollup merge of #73622 - LeSeulArtichaut:unsafe-libcore, r=nikomatsakisManish Goregaokar-43/+100
Deny unsafe ops in unsafe fns in libcore After `liballoc`, It's time for `libcore` :D I planned to do this bit by bit to avoid having a big chunk of diffs, so to make reviews easier, and to make the unsafe blocks narrower and take the time to document them properly. r? @nikomatsakis cc @RalfJung
2020-07-01Implement slice_strip featureLzu Tao-0/+62
2020-06-30Deny unsafe ops in unsafe fns, part 6LeSeulArtichaut-1/+0
And final part!!!
2020-06-30Deny unsafe ops in unsafe fns, part 5LeSeulArtichaut-43/+101
2020-06-28Rollup merge of #73577 - VillSnow:master, r=AmanieuManish Goregaokar-0/+54
Add partition_point Add partition_point in C++. Although existing binary_search in rust does not suitable when the slice has multiple hits, this function returns exact point of partition. The definition of this function is very clear and able to accept general matter, therefore you can easily get index which you want like lower/upper_bound. https://github.com/rust-lang/rfcs/issues/2184
2020-06-28Update src/libcore/slice/mod.rsVillSnow-1/+1
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
2020-06-28Update tracking issue numberVillSnow-1/+1
2020-06-28Update doc commentVillSnow-6/+10
2020-06-28Merge branch 'master' of https://github.com/VillSnow/rustVillSnow-1/+2
2020-06-28Update src/libcore/slice/mod.rsVillSnow-1/+2
Co-authored-by: Lukas Kalbertodt <lukas.kalbertodt@gmail.com>
2020-06-28Add comment on use of unsafeVillSnow-0/+9
2020-06-24Fix links in `SliceIndex` documentationLeSeulArtichaut-0/+2
2020-06-22update: doc commentVillSnow-1/+3
2020-06-21fix: doc testVillSnow-3/+3
2020-06-21Add partition_pointVillSnow-0/+38
2020-06-20Address review commentsOliver Scherer-38/+9
2020-06-19Add fuzzy pointer comparison intrinsicsOliver Scherer-2/+48
2020-06-12Rollup merge of #72906 - lzutao:migrate-numeric-assoc-consts, r=dtolnayDylan DPC-8/+4
Migrate to numeric associated consts The deprecation PR is #72885 cc #68490 cc rust-lang/rfcs#2700
2020-06-10Migrate to numeric associated constsLzu Tao-8/+4
2020-06-08Fix the typo (size of the size)Stanislav Tkach-2/+2
2020-05-31Clarify terms in doc commentsJOE1994-2/+2
Doc comments of 'copy_from_slice' say that people should use 'clone_from_slice' when 'src' doesn't implement 'Copy'. However, 'src' is a reference and it always implements 'Copy'. The term 'src' should be fixed to 'T' in the doc comments. Thank you for reviewing this PR :)
2020-05-24Use sort_unstable_by in its own docsKagami Sascha Rosylight-1/+1
2020-05-21TypoRalf Jung-1/+1
2020-05-21Improve documentation of `slice::from_raw_parts`Daniel Henry-Mantilla-1/+30
This is to provide a more explicit statement against a code pattern that many people end up coming with, since the reason of it being unsound comes from the badly known single-allocation validity rule. Providing that very pattern as a counter-example could help mitigate that. Co-authored-by: Ralf Jung <post@ralfj.de>
2020-05-20split_inclusive: add tracking issue number (72360)Pyry Kontio-13/+13
2020-05-13Use simpler impls for some `Iterator` methods for slices.Nicholas Nethercote-17/+105
The default implementations of several `Iterator` methods use `fold` or `try_fold`, which works, but is overkill for slices and bloats the amount of LLVM IR generated and consequently hurts compile times. This commit adds the simple, obvious implementations for `for_each`, `all`, `any`, `find`, `find_map`, and simplifies the existing implementations for `position` and `rposition`. These changes reduce compile times significantly on some benchmarks.
2020-05-02slice::fill: take T by value.Bastian Kauschke-6/+7
2020-04-25Bump bootstrap compilerMark Rousskov-2/+2
2020-04-20Stop accessing module level int consts via crate::<Ty>Linus Färnstrand-1/+0
2020-04-15big-O notation: parenthesis, multiplication and backticksRalf Jung-4/+4
2020-04-14Tighten time complexity on the docmi_sawa-1/+1
2020-04-05Rollup merge of #70752 - yoshuawuyts:slice_fill, r=dtolnayDylan DPC-0/+24
Add slice::fill Adds the `slice::fill` method to fill a slice with an item. This replaces manual for loops where items are copied one-by-one. This is a counterpart to C++20's [`std::fill`](https://en.cppreference.com/w/cpp/algorithm/fill) function. ## Usage ```rust let mut buf = vec![0; 10]; buf.fill(1); assert_eq!(buf, vec![1; 10]); ``` ## Performance When compiling in release mode, for `[u8]` and `[u16]` this method will optimize to a `memset(3)` call ([godbolt](https://godbolt.org/z/85El_c)). The initial implementation relies on LLVM's optimizer to make it as fast as possible for any given input. But as @jonas-schievink [pointed out](https://twitter.com/sheevink/status/1245756597453885442) this can later be optimized through specialization to guarantee it has a specific performance profile. ## Why now? Conversations about adding `slice::fill` are not new. In fact, https://github.com/rust-lang/rfcs/issues/2067 was opened 3 years ago about this exact topic. However discussion stranded while discussing implementation details, and it's not seen much forward motion since. In ["The Hunt for the Fastest Zero"](https://travisdowns.github.io/blog/2020/01/20/zero.html) Travis Downs provides disects C++'s `std::fill` performance profile on gcc, comparing it among others to `memset(3)`. Even though `memset(3)` outperforms `std::fill` in their tests, the author notes the following: > That the optimization fails, perhaps unexpectedly, in some cases is unfortunate but it’s nice that you can fix it yourself. [...] Do we throw out modern C++ idioms, at least where performance matters, for example by replacing std::fill with memset? I don’t think so. Much of the article focuses on how how to fix the performance of `std::fill` by providing specializations for specific input. In Rust we don't have any dedicated methods to fill slices with values, so it either needs to be optimized at the MIR layer, or more likely rely on LLVM's optimizer. By adding a dedicated method for filling slices with values it opens up the ability for us to in the future guarantee that e.g. `Vec<u8>` will always optimize to `memset` even in debug mode. Or perhaps provide stronger guarantees about memory when zeroing values when a certain flag is passed. But regardless of that, it improves general ergonomics of working with slices by providing a dedicated method with documentation and examples. ## References - [slice-fill prototype on docs.rs](https://docs.rs/slice-fill/1.0.1/slice_fill/) - [The Hunt For The Fastest Zero](https://travisdowns.github.io/blog/2020/01/20/zero.html) - [Safe memset for slices](https://github.com/rust-lang/rfcs/issues/2067) - [C++20 std::fill](https://en.cppreference.com/w/cpp/algorithm/fill) - [ASM output on Godbolt](https://godbolt.org/z/5-XU66)
2020-04-05Add slice::fillYoshua Wuyts-0/+24
2020-04-03Replace float module consts with assoc consts in documentationLinus Färnstrand-1/+1
2020-03-23#[track_caller] on core::ops::{Index, IndexMut}.Adam Perry-0/+6
2020-03-04Use subslice patterns in slice methodsJosh Stone-22/+8
For all of the methods that pick off the first or last element, we can use subslice patterns to implement them directly, rather than relying on deeper indexing function calls. At a minimum, this means the generated code will rely less on inlining for performance, but in some cases it also optimizes better.
2020-02-29Rollup merge of #69581 - RalfJung:align_to_mut, r=CentrilDylan DPC-1/+3
fix aliasing violation in align_to_mut Fixes https://github.com/rust-lang/rust/issues/68549 I decided to add the testcase here to make it all one PR, but if you prefer I can also add that test case in the Miri repo instead.
2020-02-29fix aliasing violation in align_to_mutRalf Jung-1/+3
2020-02-28use is_empty() instead of len() == x to determine if structs are empty.Matthias Krüger-2/+2
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2025-11-10 04:30:11 +0000