| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
It used to point to the implementation PR.
|
|
Clarifying documentation for collections::hash_map::Entry::or_insert
Previous version does not show that or_insert does not insert the passed value, as the passed value was the same value as what was already in the map.
|
|
|
|
|
|
Previous version does not show that or_insert does not insert the
passed value, as the passed value was the same value as what was
already in the map.
|
|
refactor: use shorthand fields
refactor: use shorthand for single fields everywhere (excluding tests).
|
|
|
|
Add raw_entry API to HashMap
This is a continuation of #50821.
|
|
|
|
fix some uses of pointer intrinsics with invalid pointers
[Found by miri](https://github.com/solson/miri/pull/446):
* `Vec::into_iter` calls `ptr::read` (and the underlying `copy_nonoverlapping`) with an unaligned pointer to a ZST. [According to LLVM devs](https://bugs.llvm.org/show_bug.cgi?id=38583), this is UB because it contradicts the metadata we are attaching to that pointer.
* `HashMap` creation calls `ptr:.write_bytes` on a NULL pointer with a count of 0. This is likely not currently UB *currently*, but it violates the rules we are setting in https://github.com/rust-lang/rust/pull/53783, and we might want to exploit those rules later (e.g. with more `nonnull` attributes for LLVM).
Probably what `HashMap` really should do is use `NonNull::dangling()` instead of 0 for the empty case, but that would require a more careful analysis of the code.
It seems like ideally, we should do a review of usage of such intrinsics all over libstd to ensure that they use valid pointers even when the size is 0. Is it worth opening an issue for that?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
modified to read "the first table overflows into the second, and the second into the first." plus smaller typos
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This matches std::collections
|
|
Rename OOM to allocation error
The acronym is not descriptive unless one has seen it before.
* Rename the `oom` function to `handle_alloc_error`. It was **stabilized in 1.28**, so if we do this at all we need to land it this cycle.
* Rename `set_oom_hook` to `set_alloc_error_hook`
* Rename `take_oom_hook` to `take_alloc_error_hook`
Bikeshed: `on` v.s. `for`, `alloc` v.s. `allocator`, `error` v.s. `failure`
|
|
The acronym is not descriptive unless one has seen it before.
* Rename the `oom` function to `handle_alloc_error`. It was **stabilized in 1.28**, so if we do this at all we need to land it this cycle.
* Rename `set_oom_hook` to `set_alloc_error_hook`
* Rename `take_oom_hook` to `take_alloc_error_hook`
Bikeshed: `alloc` v.s. `allocator`, `error` v.s. `failure`
|
|
|
|
The heap.rs file was already unused.
|
|
|
|
|
|
This now produces the same assembly code as the previous implementation.
|
|
|
|
|
|
The examples for both hash_map::OccupiedEntry::get_mut and
hash_map::OccupiedEntry::into_mut were almost identical. This led
to some confusion over the difference, namely why you would ever
use get_mut when into_mut gives alonger lifetime. Reddit thread:
https://www.reddit.com/r/rust/comments/8a5swr/why_does_hashmaps
This commit adds two lines and a comment to the example, to show
that the entry object can be re-used after calling get_mut.
|
|
|
|
As discussed in
https://github.com/rust-lang/rust/issues/49668#issuecomment-384893456
and subsequent, there are use-cases where the OOM handler needs to know
the size of the allocation that failed. The alignment might also be a
cause for allocation failure, so providing it as well can be useful.
|
|
was already moved to ops::RangeBounds (see #30877)
|
|
Fix some broken links in docs.
|
|
|
|
This should allow us to tighten up the [codegen][example] a bit more, avoiding a
function call across object boundaries in the default optimized case.
[example]: https://play.rust-lang.org/?gist=c1179088b0f8a4dcd93a9906463f993d&version=stable&mode=release
|
|
|
|
Tweak some stabilizations in libstd
This commit tweaks a few stable APIs in the `beta` branch before they hit
stable. The `str::is_whitespace` and `str::is_alphanumeric` functions were
deleted (added in #49381, issue at #49657). The `and_modify` APIs added
in #44734 were altered to take a `FnOnce` closure rather than a `FnMut` closure.
Closes #49581
Closes #49657
|
|
This commit tweaks a few stable APIs in the `beta` branch before they hit
stable. The `str::is_whitespace` and `str::is_alphanumeric` functions were
deleted (added in #49381, issue at #49657). The `and_modify` APIs added
in #44734 were altered to take a `FnOnce` closure rather than a `FnMut` closure.
Closes #49581
Closes #49657
|
|
|
|
Replace manual iterator exhaust with for_each(drop)
This originally added a dedicated method, `Iterator::exhaust`, and has since been replaced with `for_each(drop)`, which is more idiomatic.
<del>This is just shorthand for `for _ in &mut self {}` or `while let Some(_) = self.next() {}`. This states the intent a lot more clearly than the identical code: run the iterator to completion.
<del>At least personally, my eyes tend to gloss over `for _ in &mut self {}` without fully paying attention to what it does; having a `Drop` implementation akin to:
<del>`for _ in &mut self {}; unsafe { free(self.ptr); }`</del>
<del>Is not as clear as:
<del>`self.exhaust(); unsafe { free(self.ptr); }`
<del>Additionally, I've seen debate over whether `while let Some(_) = self.next() {}` or `for _ in &mut self {}` is more clear, whereas `self.exhaust()` is clearer than both.
|
