about summary refs log tree commit diff
path: root/src/liballoc
AgeCommit message (Collapse)AuthorLines
2020-07-01Apply documentation review suggestionsCAD97-6/+8
Co-Authored-By: Ralf Jung <post@ralfj.de>
2020-07-01Rollup merge of #73678 - Keno:patch-1, r=LukasKalbertodtManish Goregaokar-1/+4
Update Box::from_raw example to generalize better I know very little about rust, so I saw the example here ``` use std::alloc::{alloc, Layout}; unsafe { let ptr = alloc(Layout::new::<i32>()) as *mut i32; *ptr = 5; let x = Box::from_raw(ptr); } ``` and tried to generalize it by writing, ``` let layout = Layout::new::<T>(); let new_obj = unsafe { let ptr = alloc(layout) as *mut T; *ptr = obj; Box::from_raw(ptr) }; ``` for some more complicated `T`, which ended up crashing with SIGSEGV, because it tried to `drop_in_place` the previous object in `ptr` which is of course garbage. I think that changing this example to use `.write` instead would be a good idea to suggest the correct generalization. It is also more consistent with other documentation items in this file, which use `.write`. I also added a comment to explain it, but I'm not too attached to that, and can see it being too verbose in this place.
2020-07-01Rollup merge of #73466 - matthiaskrgr:char_into_string, r=dtolnayManish Goregaokar-0/+15
impl From<char> for String This allows us to write ````rust fn char_to_string() -> String { 'a'.into() } ```` which was not possible before.
2020-06-30Clarify when rc::data_offset is safeCAD97-1/+20
2020-06-30Fix invalid pointer deref in Weak::as_ptrCAD97-2/+2
2020-06-30Clarify safety comment for A|Rc::as_ptrCAD97-10/+6
2020-06-30Avoid `unwrap_or_else` in `RawVec::allocate_in`.Nicholas Nethercote-3/+14
This reduces the amount of LLVM IR generated by up to 1 or 2%.
2020-06-29Auto merge of #73391 - pickfire:liballoc-panic-doc, r=Mark-Simulacrumbors-11/+5
Add liballoc doc panic detail according to RawVec
2020-06-28Use impl for Weak::as_ptr that works for unsized TCAD97-22/+26
2020-06-28Do not require ptr validity in rc::data_offsetCAD97-2/+3
2020-06-28Use raw_ref_op in A|Rc::as_ptrCAD97-10/+3
2020-06-28Remove `const_if_match` feature gate from librariesDylan MacKenzie-1/+1
2020-06-26Rollup merge of #73765 - kraai:remove-blank-line, r=jonas-schievinkManish Goregaokar-1/+0
Remove blank line
2020-06-26Rollup merge of #73627 - ssomers:btree_iter_min_max, r=Mark-SimulacrumManish Goregaokar-0/+141
Shortcuts for min/max on double-ended BTreeMap/BTreeSet iterators Closes #59947: a performance tweak that might benefit some. Optimizes `min` and `max ` on all btree double-ended iterators that do not drop, i.e. the iterators created by: - `BTreeMap::iter` - `BTreeMap::iter_mut` - `BTreeMap::keys` and `BTreeSet::iter` - `BTreeMap::range` and `BTreeSet::range` - `BTreeMap::range_mut` Also in these (currently) single-ended iterators, but obviously for `min` only: - `BTreeSet::difference` - `BTreeSet::intersection` - `BTreeSet::symmetric_difference` - `BTreeSet::union` Did not do this in iterators created by `into_iter` to preserve drop order, as outlined in #62316. Did not do this in iterators created by `drain_filter`, possibly to preserve drop order, possibly to preserve predicate invocation, mostly to not have to think about it too hard (I guess maybe it wouldn't be a change for `min`, which is the only shortcut possible in this single-ended iterator).
2020-06-26Rollup merge of #73529 - pickfire:liballoc-specfromelem-i8, r=cuviperManish Goregaokar-1/+15
Add liballoc impl SpecFromElem for i8 Speedup vec![1_i8; N] for non-zero element. Before test do_bench_from_elem_i8 ... bench: 130 ns/iter (+/- 7) = 61 MB/s test do_bench_from_elem_u8 ... bench: 121 ns/iter (+/- 4) = 66 MB/s After test do_bench_from_elem_i8 ... bench: 123 ns/iter (+/- 7) = 65 MB/s test do_bench_from_elem_u8 ... bench: 121 ns/iter (+/- 5) = 66 MB/s No speed difference if element is already zero. ```rust #[bench] fn do_bench_from_elem_i8(b: &mut Bencher) { b.bytes = 8 as u64; b.iter(|| { let dst = ve::vec![10_i8; 100]; assert_eq!(dst.len(), 100); assert!(dst.iter().all(|x| *x == 10)); }) } ``` As suggested by @cuviper https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/SpecForElem.20for.20other.20integers r? @cuviper CC @joshtriplett Edit: Wow, I just realized both reviewers are Josh.
2020-06-27Add liballoc doc panic detail according to RawVecIvan Tham-11/+5
2020-06-26Remove blank lineKRAAI, MATTHEW [VISUS]-1/+0
2020-06-26Shortcuts for min/max on ordinary BTreeMap/BTreeSet iteratorsStein Somers-0/+141
2020-06-26Rollup merge of #73729 - nellshamrell:disable-collectionsbenches-android, ↵Manish Goregaokar-0/+3
r=sfackler disable collectionbenches for android Fixes #73535 Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
2020-06-25disable collectionbenches for androidNell Shamrell-0/+3
Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
2020-06-25Rollup merge of #73616 - pickfire:liballoc-hash, r=joshtriplettDylan DPC-2/+2
Liballoc minor hash import tweak
2020-06-25Rollup merge of #72700 - davidtwco:issue-66220-improper-ctypes-declarations, ↵Dylan DPC-0/+2
r=lcnr,varkor `improper_ctypes_definitions` lint Addresses #19834, #66220, and #66373. This PR takes another attempt at #65134 (reverted in #66378). Instead of modifying the existing `improper_ctypes` lint to consider `extern "C" fn` definitions in addition to `extern "C" {}` declarations, this PR adds a new lint - `improper_ctypes_definitions` - which only applies to `extern "C" fn` definitions. In addition, the `improper_ctype_definitions` lint differs from `improper_ctypes` by considering `*T` and `&T` (where `T: Sized`) FFI-safe (addressing #66220). There wasn't a clear consensus in #66220 (where the issues with #65134 were primarily discussed) on the approach to take, but there has [been some discussion in Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.2366220.20improper_ctypes.20definitions.20vs.20declarations/near/198903086). I fully expect that we'll want to iterate on this before landing. cc @varkor + @shepmaster (from #19834) @hanna-kruppe (active in discussing #66220), @SimonSapin (#65134 caused problems for Servo, want to make sure that this PR doesn't)
2020-06-24Rollup merge of #73667 - nrabulinski:master, r=Dylan-DPCDylan DPC-1/+1
Update BTreeMap::new() doc Updates the documentation according to [this comment](https://github.com/rust-lang/rust/pull/72876/files/0c5c644c91edf6ed949cfa5ffc524f43369df604#r433232581) on #72876
2020-06-24Rollup merge of #73638 - yuqio:remove-unused-crate-imports, r=nikomatsakisDylan DPC-2/+0
Remove unused crate imports in 2018 edition crates Closes #73570
2020-06-24lints: add `improper_ctypes_definitions`David Wood-0/+2
This commit adds a new lint - `improper_ctypes_definitions` - which functions identically to `improper_ctypes`, but on `extern "C" fn` definitions (as opposed to `improper_ctypes`'s `extern "C" {}` declarations). Signed-off-by: David Wood <david@davidtw.co>
2020-06-23Update Box::from_raw example to generalize betterKeno Fischer-1/+4
I know very little about rust, so I saw this example and tried to generalize it by writing, ``` let layout = Layout::new::<T>(); let new_obj = unsafe { let ptr = alloc(layout) as *mut T; *ptr = obj; Box::from_raw(ptr) }; ``` for some more complicated `T`, which ended up crashing with SIGSEGV, because it tried to `drop_in_place` the previous object in `ptr` which is of course garbage. I also added a comment that explains why `.write` is used, but I think adding that comment is optional and may be too verbose here. I do however think that changing this example is a good idea to suggest the correct generalization. `.write` is also used in most of the rest of the documentation here, even if the example is `i32`, so it would additionally be more consistent.
2020-06-23Rollup merge of #72876 - TrolledWoods:patch-2, r=Dylan-DPCManish Goregaokar-0/+2
Mention that BTreeMap::new() doesn't allocate I think it would be nice to mention this, so you don't have to dig through the src to look at the definition of new().
2020-06-23Update map.rsNikodem Rabuliński-1/+1
2020-06-23Rollup merge of #73398 - oli-obk:const_raw_ptr_cmp, r=varkor,RalfJung,nagisaManish Goregaokar-1/+1
A way forward for pointer equality in const eval r? @varkor on the first commit and @RalfJung on the second commit cc #53020
2020-06-23Remove unused crate imports in 2018 edition cratesyuqio-2/+0
2020-06-22Rollup merge of #71660 - sollyucko:master, r=dtolnayDylan DPC-11/+70
impl PartialEq<Vec<B>> for &[A], &mut [A] https://github.com/rust-lang/rfcs/issues/2917
2020-06-22Liballoc minor hash import tweakIvan Tham-2/+2
2020-06-20Update stability attribute of new Vec PartialEq implsDavid Tolnay-13/+13
2020-06-20impl PartialEq<Vec<B>> for &[A], &mut [A]Solomon Ucko-0/+59
2020-06-20Satisfy tidyOliver Scherer-1/+1
2020-06-20Remove uses of `Vec::remove_item`Lukas Kalbertodt-16/+0
2020-06-20Deprecate `Vec::remove_item`Lukas Kalbertodt-10/+8
2020-06-20Add liballoc impl SpecFromElem for i8Ivan Tham-1/+15
Speedup vec![1_i8; N] for non-zero element. Before test do_bench_from_elem_i8 ... bench: 130 ns/iter (+/- 7) = 61 MB/s test do_bench_from_elem_u8 ... bench: 121 ns/iter (+/- 4) = 66 MB/s After test do_bench_from_elem_i8 ... bench: 123 ns/iter (+/- 7) = 65 MB/s test do_bench_from_elem_u8 ... bench: 121 ns/iter (+/- 5) = 66 MB/s No speed difference if element is already zero. #[bench] fn do_bench_from_elem_i8(b: &mut Bencher) { b.bytes = 8 as u64; b.iter(|| { let dst = ve::vec![10_i8; 100]; assert_eq!(dst.len(), 100); assert!(dst.iter().all(|x| *x == 10)); }) } As suggested by @cuviper https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/SpecForElem.20for.20other.20integers
2020-06-19Rollup merge of #73465 - lzutao:spec-char-tostring, r=sfacklerManish Goregaokar-0/+8
Add specialization of `ToString for char` Closes #73462
2020-06-19Rollup merge of #72709 - LeSeulArtichaut:unsafe-liballoc, r=nikomatsakisManish Goregaokar-257/+387
`#[deny(unsafe_op_in_unsafe_fn)]` in liballoc This PR proposes to make use of the new `unsafe_op_in_unsafe_fn` lint, i.e. no longer consider the body of an unsafe function as an unsafe block and require explicit unsafe block to perform unsafe operations. This has been first (partly) suggested by @Mark-Simulacrum in https://github.com/rust-lang/rust/pull/69245#issuecomment-587817065 Tracking issue for the feature: #71668. ~~Blocked on #71862.~~ r? @Mark-Simulacrum cc @nikomatsakis can you confirm that those changes are desirable? Should I restrict it to only BTree for the moment?
2020-06-19Apply suggestions from code reviewLeSeulArtichaut-9/+11
Co-authored-by: nikomatsakis <niko@alum.mit.edu>
2020-06-19`#[deny(unsafe_op_in_unsafe_fn)]` in liballocLeSeulArtichaut-261/+389
2020-06-19Rollup merge of #73479 - pickfire:liballoc-spell, r=dtolnayRalf Jung-3/+3
Minor tweaks to liballoc
2020-06-19Rollup merge of #73459 - cuviper:into_boxed_slice-unicast, r=dtolnayRalf Jung-1/+1
Reduce pointer casts in Box::into_boxed_slice We only need to cast the pointer once to change `Box<T>` to an array `Box<[T; 1]>`, then we can let unsized coercion return `Box<[T]>`.
2020-06-19Rearrange liballoc __impl_slice_eq1Ivan Tham-1/+1
2020-06-19Liballoc clean up macro_rules styleIvan Tham-1/+1
2020-06-19Fix liballoc doc spellingIvan Tham-1/+1
2020-06-18Ensure std benchmarks get tested.Eric Huss-0/+1
2020-06-18add test for char into stringMatthias Krüger-0/+7
2020-06-18impl From<char> for StringMatthias Krüger-0/+8
This allows us to write fn char_to_string() -> String { 'a'.into() } which was not possible before.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-12 07:16:19 +0000