rust - https://github.com/rust-lang/rust

Age	Commit message (Collapse)	Author	Lines
2020-07-27	mv std libs to library/	mark	-47/+0

2020-03-28	Make fields in `MemoryBlock` public	Tim Diekmann	-1/+1

2020-03-26	Remove alignment from `MemoryBlock`	Tim Diekmann	-5/+2

2020-03-26	Fix issues from review and unsoundness of `RawVec::into_box`	Tim Diekmann	-3/+6

2020-03-26	Overhaul of the `AllocRef` trait to match allocator-wg's latest consens	Tim Diekmann	-2/+8

2020-03-03	Remove `usable_size` APIs	Tim Diekmann	-1/+1

2020-01-27	Rename `Alloc` to `AllocRef`	Tim Diekmann	-2/+2

2019-12-22	Format the world	Mark Rousskov	-8/+15

2019-07-02	test more possible overaligned requests	Ralf Jung	-15/+17

2019-02-13	review failures in heap, slice, vec	Ralf Jung	-2/+0

2019-02-10	libs: doc comments	Alexander Regueiro	-1/+1

2019-02-07	disable tests in Miri	Ralf Jung	-0/+2

2018-12-25	Remove licenses	Mark Rousskov	-10/+0

2018-11-11	std: Delete the `alloc_system` crate	Alex Crichton	-2/+1
	This commit deletes the `alloc_system` crate from the standard distribution. This unstable crate is no longer needed in the modern stable global allocator world, but rather its functionality is folded directly into the standard library. The standard library was already the only stable location to access this crate, and as a result this should not affect any stable code.
2018-11-02	Remove all jemalloc-related content	Alex Crichton	-3/+0
	This commit removes all jemalloc related submodules, configuration, etc, from the bootstrap, from the standard library, and from the compiler. This will be followed up with a change to use jemalloc specifically as part of rustc on blessed platforms.
2018-04-12	Use NonNull<Void> instead of *mut u8 in the Alloc trait	Mike Hommey	-1/+2
	Fixes #49608
2018-04-12	Actually deprecate the Heap type	Simon Sapin	-2/+2

2017-11-20	alloc_jemalloc: don’t assume MIN_ALIGN for small sizes	Simon Sapin	-0/+5
	See previous commit’s message for what is expected of allocators in general, and https://github.com/jemalloc/jemalloc/issues/1072 for discussion of what jemalloc does specifically.
2017-11-20	alloc_system: don’t assume MIN_ALIGN for small sizes, fix #45955	Simon Sapin	-0/+40
	The GNU C library (glibc) is documented to always allocate with an alignment of at least 8 or 16 bytes, on 32-bit or 64-bit platforms: https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html This matches our use of `MIN_ALIGN` before this commit. However, even when libc is glibc, the program might be linked with another allocator that redefines the `malloc` symbol and friends. (The `alloc_jemalloc` crate does, in some cases.) So `alloc_system` doesn’t know which allocator it calls, and needs to be conservative in assumptions it makes. The C standard says: https://port70.net/%7Ensz/c/c11/n1570.html#7.22.3 > The pointer returned if the allocation succeeds is suitably aligned > so that it may be assigned to a pointer to any type of object > with a fundamental alignment requirement https://port70.net/~nsz/c/c11/n1570.html#6.2.8p2 > A fundamental alignment is represented by an alignment less than > or equal to the greatest alignment supported by the implementation > in all contexts, which is equal to `_Alignof (max_align_t)`. `_Alignof (max_align_t)` depends on the ABI and doesn’t seem to have a clear definition, but it seems to match our `MIN_ALIGN` in practice. However, the size of objects is rounded up to the next multiple of their alignment (since that size is also the stride used in arrays). Conversely, the alignment of a non-zero-size object is at most its size. So for example it seems ot be legal for `malloc(8)` to return a pointer that’s only 8-bytes-aligned, even if `_Alignof (max_align_t)` is 16.