This commit is an implementation of [RFC 1183][rfc] which allows swapping out
the default allocator on nightly Rust. No new stable surface area should be
added as a part of this commit.
[rfc]: https://github.com/rust-lang/rfcs/pull/1183
Two new attributes have been added to the compiler:
* `#![needs_allocator]` - this is used by liballoc (and likely only liballoc) to
indicate that it requires an allocator crate to be in scope.
* `#![allocator]` - this is a indicator that the crate is an allocator which can
satisfy the `needs_allocator` attribute above.
The ABI of the allocator crate is defined to be a set of symbols that implement
the standard Rust allocation/deallocation functions. The symbols are not
currently checked for exhaustiveness or typechecked. There are also a number of
restrictions on these crates:
* An allocator crate cannot transitively depend on a crate that is flagged as
needing an allocator (e.g. allocator crates can't depend on liballoc).
* There can only be one explicitly linked allocator in a final image.
* If no allocator is explicitly requested one will be injected on behalf of the
compiler. Binaries and Rust dylibs will use jemalloc by default where
available and staticlibs/other dylibs will use the system allocator by
default.
Two allocators are provided by the distribution by default, `alloc_system` and
`alloc_jemalloc` which operate as advertised.
Closes#27389
They're only enabled in debug builds, but a panic is usually more
welcome than UB in debug builds.
Previous review at https://github.com/rust-lang/rust/pull/22069
r? @Gankro
cc @huon
This commit modifies the standard library and its dependencies to link correctly
when built against MUSL. This primarily ensures that the right libraries are
linked against and when they're linked against they're linked against
statically.
Changes the style guidelines regarding unit tests to recommend using a
sub-module named "tests" instead of "test" for unit tests as "test"
might clash with imports of libtest.
This commit stabilizes the `std::num` module:
* The `Int` and `Float` traits are deprecated in favor of (1) the
newly-added inherent methods and (2) the generic traits available in
rust-lang/num.
* The `Zero` and `One` traits are reintroduced in `std::num`, which
together with various other traits allow you to recover the most
common forms of generic programming.
* The `FromStrRadix` trait, and associated free function, is deprecated
in favor of inherent implementations.
* A wide range of methods and constants for both integers and floating
point numbers are now `#[stable]`, having been adjusted for integer
guidelines.
* `is_positive` and `is_negative` are renamed to `is_sign_positive` and
`is_sign_negative`, in order to address #22985
* The `Wrapping` type is moved to `std::num` and stabilized;
`WrappingOps` is deprecated in favor of inherent methods on the
integer types, and direct implementation of operations on
`Wrapping<X>` for each concrete integer type `X`.
Closes#22985Closes#21069
[breaking-change]
r? @alexcrichton
This commit stabilizes the `std::num` module:
* The `Int` and `Float` traits are deprecated in favor of (1) the
newly-added inherent methods and (2) the generic traits available in
rust-lang/num.
* The `Zero` and `One` traits are reintroduced in `std::num`, which
together with various other traits allow you to recover the most
common forms of generic programming.
* The `FromStrRadix` trait, and associated free function, is deprecated
in favor of inherent implementations.
* A wide range of methods and constants for both integers and floating
point numbers are now `#[stable]`, having been adjusted for integer
guidelines.
* `is_positive` and `is_negative` are renamed to `is_sign_positive` and
`is_sign_negative`, in order to address #22985
* The `Wrapping` type is moved to `std::num` and stabilized;
`WrappingOps` is deprecated in favor of inherent methods on the
integer types, and direct implementation of operations on
`Wrapping<X>` for each concrete integer type `X`.
Closes#22985Closes#21069
[breaking-change]
This functions swaps the order of arguments to a few functions that previously
took (output, input) parameters, but now take (input, output) parameters (in
that order).
The affected functions are:
* ptr::copy
* ptr::copy_nonoverlapping
* slice::bytes::copy_memory
* intrinsics::copy
* intrinsics::copy_nonoverlapping
Closes#22890
[breaking-change]
When this attribute is applied to a function, its return value gets the
noalias attribute, which is how you tell LLVM that the function returns
a "new" pointer that doesn't alias anything accessible to the caller,
i.e. it acts like a memory allocator.
Plain malloc doesn't need this attribute because LLVM already knows
about malloc and adds the attribute itself.
This is the kind of change that one is expected to need to make to
accommodate overloaded-`box`.
----
Note that this is not *all* of the changes necessary to accommodate
Issue 22181. It is merely the subset of those cases where there was
already a let-binding in place that made it easy to add the necesasry
type ascription.
(For unnamed intermediate `Box` values, one must go down a different
route; `Box::new` is the option that maximizes portability, but has
potential inefficiency depending on whether the call is inlined.)
----
There is one place worth note, `run-pass/coerce-match.rs`, where I
used an ugly form of `Box<_>` type ascription where I would have
preferred to use `Box::new` to accommodate overloaded-`box`. I
deliberately did not use `Box::new` here, because that is already done
in coerce-match-calls.rs.
----
Precursor for overloaded-`box` and placement-`in`; see Issue 22181.
This commit performs a second pass for stabilization over the `std::ptr` module.
The specific actions taken were:
* The `RawPtr` trait was renamed to `PtrExt`
* The `RawMutPtr` trait was renamed to `MutPtrExt`
* The module name `ptr` is now stable.
* These functions were all marked `#[stable]` with no modification:
* `null`
* `null_mut`
* `swap`
* `replace`
* `read`
* `write`
* `PtrExt::is_null`
* `PtrExt::offset`
* These functions remain unstable:
* `as_ref`, `as_mut` - the return value of an `Option` is not fully expressive
as null isn't the only bad value, and it's unclear
whether we want to commit to these functions at this
time. The reference/lifetime semantics as written are
also problematic in how they encourage arbitrary
lifetimes.
* `zero_memory` - This function is currently not used at all in the
distribution, and in general it plays a broader role in the
"working with unsafe pointers" story. This story is not yet
fully developed, so at this time the function remains
unstable for now.
* `read_and_zero` - This function remains unstable for largely the same
reasons as `zero_memory`.
* These functions are now all deprecated:
* `PtrExt::null` - call `ptr::null` or `ptr::null_mut` instead.
* `PtrExt::to_uint` - use an `as` expression instead.
* `PtrExt::is_not_null` - use `!p.is_null()` instead.
In regards to:
https://github.com/rust-lang/rust/issues/19253#issuecomment-64836729
This commit:
* Changes the #deriving code so that it generates code that utilizes fewer
reexports (in particur Option::* and Result::*), which is necessary to
remove those reexports in the future
* Changes other areas of the codebase so that fewer reexports are utilized
Adds the ability to use a custom allocator heap by passing either --cfg
external_crate and --extern external=<allocator_crate_name> or --cfg
external_funcs and defining the allocator functions prefixed by 'rust_'
somewhere.
This is useful for many reasons including OS/embedded development, and
allocator development and testing.
The real size is also more useful than just a boolean, and the caller
can easily determine if the operation failed from the real size. In most
cases, the caller is only going to be growing the allocation so a branch
can be avoided.
[breaking-change]
The C standard library functions should be used directly. The quirky
NULL / zero-size allocation workaround is no longer necessary and was
adding an extra branch to the allocator code path in a build without
jemalloc. This is a small step towards liballoc being compatible with
handling OOM errors instead of aborting (#18292).
[breaking-change]
With MIN_ALIGN as a static, other crates don't have access to its value
at compile time, because it is an extern global. That means that the
checks against it can't be optimized out, which is rather unfortunate.
So let's make it a constant instead.
Nick Cameron
Alex Crichton
Peter Atashian
Steve Klabnik
Clark Gaebel
Nick Hamann
Johannes Oertel
Krzysztof Drewniak
bors
Aaron Turon
Jorge Aparicio
Björn Steinbrink
Felix S. Klock II
Valerii Hiora
we
Tobias Bucher
Manish Goregaokar
Brian Anderson
Richo Healey
John Ericson
Akos Kiss
Corey Farwell
Alexander Light
Daniel Micay