rust/src/libstd/collections/hash, branch 1.31.1https://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=1.31.12018-09-16T18:03:39+00:00Auto merge of #53804 - RalfJung:ptr-invalid, r=nagisa2018-09-16T18:03:39+00:00borsbors@rust-lang.org2018-09-16T18:03:39+00:00urn:sha1:8a2dec6e583bc6425a91b277bdc6c602088845f1
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?
Eliminate unused variable warning2018-09-13T20:48:09+00:00Jonathan Behrensfintelia@gmail.com2018-09-13T20:48:09+00:00urn:sha1:e9583628b2dcc389a69999e5ff431b70c1561488Remove println!() statement from HashMap unit test2018-09-13T18:58:13+00:00Jonathan Behrensfintelia@gmail.com2018-09-13T18:58:13+00:00urn:sha1:1ad0919fa9a9404ba82125c2c654f3d8c25a202bfix typos in growth algo description2018-09-10T16:02:16+00:00Valdgm97@cornell.edu2018-09-10T16:02:16+00:00urn:sha1:abe0f027ae23b47dfabeb217aaa56b155d565ae3
modified to read "the first table overflows into the second, and the second into the first." plus smaller typosFix invalid urls2018-09-06T21:32:30+00:00Guillaume Gomezguillaume1.gomez@gmail.com2018-07-01T16:51:39+00:00urn:sha1:c1ad1b03388778893159c549db82b2716c71f102fix some uses of pointer intrinsics with invalid pointers2018-08-29T21:08:47+00:00Ralf Jungpost@ralfj.de2018-08-29T21:08:47+00:00urn:sha1:61f0a2b3fd961c9ae6d327d384bcffabf89a1c26Replace usages of ptr::offset with ptr::{add,sub}.2018-08-20T11:28:34+00:00Corey Farwellcoreyf@rwell.org2018-08-20T02:16:22+00:00urn:sha1:993fb934640b7e514f3c629c33a2698a83ed8c3eMove core::alloc::CollectionAllocErr to alloc::collections2018-06-29T12:01:33+00:00Simon Sapinsimon.sapin@exyr.org2018-06-15T01:56:35+00:00urn:sha1:b0547cea0ae50f49619ded26f43d0d55a1674b14Auto merge of #51543 - SimonSapin:oom, r=SimonSapin2018-06-19T19:22:12+00:00borsbors@rust-lang.org2018-06-19T19:22:12+00:00urn:sha1:d692ab406ebab720f99f950ac3e9aba1e01296af
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`
Rename OOM to allocation error2018-06-18T19:41:24+00:00Simon Sapinsimon.sapin@exyr.org2018-06-13T22:32:30+00:00urn:sha1:2b789bd0570983e82533f9ed30c80312ac334694
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`