about summary refs log tree commit diff
path: root/src/liballoc_system
AgeCommit message (Collapse)AuthorLines
2018-07-31Fix coding style.Colin Finck-2/+8
2018-07-30Add targets for HermitCore (https://hermitcore.org) to the Rust compiler and ↵Colin Finck-2/+2
port libstd to it. As a start, the port uses the simplest possible configuration (no jemalloc, abort on panic) and makes use of existing Unix-specific code wherever possible. It adds targets for x86_64 (current main HermitCore platform) and aarch64 (HermitCore platform under development). Together with the patches to "liblibc" and "llvm", this enables HermitCore applications to be written in Rust.
2018-07-25Deny bare_trait_objects globallyTatsuyuki Ishi-1/+0
2018-07-12Deny bare trait objects in the rest of rustljedrz-0/+1
2018-06-11Move Unstable Book sections for #[global_allocator] and System to std::alloc ↵Simon Sapin-0/+23
docs
2018-06-11Remove some '#[feature]' attributes for stabilized featuresSimon Sapin-1/+0
2018-06-11Stabilize the `System` allocatorSimon Sapin-4/+4
2018-06-11Document memory allocation APIsSimon Sapin-0/+1
Add some docs where they were missing, attempt to fix them where they were out of date.
2018-06-11Remove alloc::Opaque and use *mut u8 as pointer type for GlobalAllocMike Hommey-46/+43
2018-05-17Switch to 1.26 bootstrap compilerMark Simulacrum-27/+0
2018-04-22Remove Alloc::oomSteven Fackler-70/+0
2018-04-22Replace GlobalAlloc::oom with a lang itemSteven Fackler-1/+1
2018-04-12Rename alloc::Void to alloc::OpaqueSimon Sapin-52/+51
2018-04-12Remove conversions for allocated pointersSimon Sapin-8/+8
One was now unused, and `NonNull::new(…).ok_or(AllocErr)` feels short enough for the few cases that need the other conversion.
2018-04-12Use NonNull<Void> instead of *mut u8 in the Alloc traitMike Hommey-14/+15
Fixes #49608
2018-04-12Restore Global.oom() functionalitySimon Sapin-0/+4
… now that #[global_allocator] does not define a symbol for it
2018-04-12Remove `impl Alloc for &'a System`Simon Sapin-113/+28
This was relevant to `#[global_allocator]`, which is now based on `GlobalAlloc` trait instead.
2018-04-12Move platform-specific OOM handling to functionsSimon Sapin-73/+58
2018-04-12Conversions between Result<*mut u8, AllocErr>> and *mut VoidSimon Sapin-18/+3
2018-04-12realloc with a new size only, not a full new layout.Simon Sapin-25/+17
Changing the alignment with realloc is not supported.
2018-04-12Add FIXME comments for Void::null_mut usageSimon Sapin-0/+1
2018-04-12Remove the now-unit-struct AllocErr parameter of oom()Simon Sapin-6/+6
2018-04-12Implement GlobalAlloc for SystemSimon Sapin-128/+141
2018-04-12Make AllocErr a zero-size unit structSimon Sapin-15/+9
2018-04-12Update to most recent version of dlmallocAlex Crichton-43/+19
Inline the definition of `GlobalAlloc` for `dlmalloc` on wasm and don't rely on usage of unstable features in `dlmalloc` itself.
2018-04-12Separate alloc::heap::Alloc trait for stage0 #[global_allocator]Simon Sapin-5/+4
2018-04-08Move deny(warnings) into rustbuildMark Simulacrum-1/+0
This permits easier iteration without having to worry about warnings being denied. Fixes #49517
2018-04-07Inject the `compiler_builtins` crate whenever the `core` crate is injectedOliver Schneider-0/+1
2018-04-04Auto merge of #49573 - glandium:huge-align, r=SimonSapinbors-0/+8
Reject huge alignments on macos with system allocator only ef8804ba277b055fdc3e6d148e680e3c1b597ad8 addressed #30170 by rejecting huge alignments at the allocator API level, transforming a specific platform bug/limitation into an enforced API limitation on all platforms. This change essentially reverts that commit, and instead makes alloc() itself return AllocErr::Unsupported when receiving huge alignments. This was discussed in https://github.com/rust-lang/rust/issues/32838#issuecomment-368348408 and following.
2018-04-02Use Alloc and Layout from core::heap.Mike Hommey-7/+4
94d1970bba87f2d2893f6e934e4c3f02ed50604d moved the alloc::allocator module to core::heap, moving e.g. Alloc and Layout out of the alloc crate. While alloc::heap reexports them, it's better to use them from where they really come from.
2018-04-02Reject huge alignments on macos with system allocator onlyMike Hommey-0/+8
ef8804ba277b055fdc3e6d148e680e3c1b597ad8 addressed #30170 by rejecting huge alignments at the allocator API level, transforming a specific platform bug/limitation into an enforced API limitation on all platforms. This change essentially reverts that commit, and instead makes alloc() itself return AllocErr::Unsupported when receiving huge alignments. This was discussed in https://github.com/rust-lang/rust/issues/32838#issuecomment-368348408 and following.
2017-12-31Build the right platform module on CloudABI.Ed Schouten-2/+2
After #47089 lands, CloudABI will no longer be considered UNIX. We need to pick the right allocator flavour now.
2017-12-27Disable printing of error message on file descriptor 2 on CloudABI.Ed Schouten-0/+10
As CloudABI is a capability-based runtime environment, file descriptors are the mechanism that grants rights to a process. These file descriptors may be passed into processes on startup using a utility called cloudabi-run. Unlike the POSIX shell, cloudabi-run does not follow the UNIX model where file descriptors 0, 1 and 2 represent stdin, stdout and stderr. There can be arbitrary many (or few) file descriptors that can be provided. For this reason, CloudABI's C library also doesn't define STD*_FILENO. liblibc should also not declare these. Disable the code in liballoc_system that tries to print error messages over file descriptor 2. For now, let's keep this function quiet. We'll see if we can think of some other way to log this in the future.
2017-11-20Remove comment about a branch being optimized out, fix #45831Simon Sapin-2/+1
Most often, this code is used through the `std::heap::Heap` and `#[gloabal_allocator]` indirection, so this branch is not optimized out anymore.
2017-11-20alloc_system: don’t assume MIN_ALIGN for small sizes, fix #45955Simon Sapin-3/+3
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.
2017-11-19std: Add a new wasm32-unknown-unknown targetAlex Crichton-0/+94
This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a "custom linker" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed, rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error, but anything related to allocation works (aka `HashMap`, `Vec`, etc). * Naturally, any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The "linking" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target, so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's "production ready". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored, but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the "smallest possible wasm module" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final "bloat" in vanilla rustc (again, a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this, particularly on the various integration points if you've got better ideas of how to approach them!
2017-10-12Fix out of date unstable book entries for `alloc_*` features.Simon Sapin-1/+1
2017-09-10Autodetect the type of allocator crate usedMichal 'vorner' Vaner-0/+3
Annotate the allocator crates (allocator_system, allocator_jemalloc) by the type of allocator they are. If one is requested as an exe allocator, detect its type by the flags. This has the effect that using this (de jure wrong) configuration in the target spec works instead of producing a really unhelpful and arcane linker error: "exe-allocation-crate": "alloc_system" Fixes #43524.
2017-09-06Use memalign instead of posix_memalign for Solarisbgermann-2/+2
As pointed out in https://github.com/rust-lang/libc/commit/deb61c8, Solaris 10 does not support posix_memalign. Use memalign for all Solaris versions instead. With this change applied I am able to cross-build rustc for Solaris 10.
2017-08-25*: remove crate_{name,type} attributesTamir Duberstein-2/+0
Fixes #41701.
2017-07-25Bump master to 1.21.0Alex Crichton-352/+69
This commit bumps the master branch's version to 1.21.0 and also updates the bootstrap compiler from the freshly minted beta release.
2017-07-05rustc: Implement the #[global_allocator] attributeAlex Crichton-142/+608
This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented, allowing much more freedom in terms of how this feature is implemented. cc #27389
2017-06-02Improve reallocation in alloc_system on WindowsPeter Atashian-17/+20
2017-04-15Specialize Vec::from_elem<u8> to use calloc or memsetMatt Brubeck-3/+31
Fixes #38723.
2017-01-08Auto merge of #38679 - alexcrichton:always-deny-warnings, r=nrcbors-1/+1
Remove not(stage0) from deny(warnings) Historically this was done to accommodate bugs in lints, but there hasn't been a bug in a lint since this feature was added which the warnings affected. Let's completely purge warnings from all our stages by denying warnings in all stages. This will also assist in tracking down `stage0` code to be removed whenever we're updating the bootstrap compiler.
2017-01-01Merge branch 'master' into sparc64Seo Sanghyeon-0/+1
2016-12-30std: Don't build docs for misc facade cratesAlex Crichton-0/+1
Retain the same behavior as stable. Closes #38319
2016-12-29Remove not(stage0) from deny(warnings)Alex Crichton-1/+1
Historically this was done to accommodate bugs in lints, but there hasn't been a bug in a lint since this feature was added which the warnings affected. Let's completely purge warnings from all our stages by denying warnings in all stages. This will also assist in tracking down `stage0` code to be removed whenever we're updating the bootstrap compiler.
2016-12-29liballoc_*: add MIN_ALIGN for sparc64Jonathan A. Kollasch-1/+2
2016-12-20Switch back to alloc_systemJeremy Soller-47/+4
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-14 21:43:31 +0000