These guarantee that always the requested slice size will be returned
and any leftoever elements at the end will be ignored. It allows llvm to
get rid of bounds checks in the code using the iterator.
This is inspired by the same iterators provided by ndarray.
See https://github.com/rust-lang/rust/issues/47115
This commit removes the `rand` crate from the standard library facade as
well as the `__rand` module in the standard library. Neither of these
were used in any meaningful way in the standard library itself. The only
need for randomness in libstd is to initialize the thread-local keys of
a `HashMap`, and that unconditionally used `OsRng` defined in the
standard library anyway.
The cruft of the `rand` crate and the extra `rand` support in the
standard library makes libstd slightly more difficult to port to new
platforms, namely WebAssembly which doesn't have any randomness at all
(without interfacing with JS). The purpose of this commit is to clarify
and streamline randomness in libstd, focusing on how it's only required
in one location, hashmap seeds.
Note that the `rand` crate out of tree has almost always been a drop-in
replacement for the `rand` crate in-tree, so any usage (accidental or
purposeful) of the crate in-tree should switch to the `rand` crate on
crates.io. This then also has the further benefit of avoiding
duplication (mostly) between the two crates!
We don't want to stabilize them now already. The goal of this set of
commits is just to add inherent methods to the four types. Stabilizing
all of those methods can be done later.
Add iterator method .rfold(init, function); the reverse of fold
rfold is the reverse version of fold.
Fold allows iterators to implement a different (non-resumable) internal
iteration when it is more efficient than the external iteration implemented
through the next method. (Common examples are VecDeque and .chain()).
Introduce rfold() so that the same customization is available for reverse
iteration. This is achieved by both adding the method, and by having the
Rev\<I> adaptor connect Rev::rfold → I::fold and Rev::fold → I::rfold.
On the surface, rfold(..) is just .rev().fold(..), but the special case
implementations allow a data structure specific fold to be used through for
example .iter().rev(); we thus have gains even for users never calling exactly
rfold themselves.
std: Mark allocation functions as nounwind
This commit flags all allocation-related functions in liballoc as "this can't
unwind" which should largely resolve the size-related issues found on #42808.
The documentation on the trait was updated with such a restriction (they can't
panic) as well as some other words about the relative instability about
implementing a bullet-proof allocator.
Closes#42808
This commit flags all allocation-related functions in liballoc as "this can't
unwind" which should largely resolve the size-related issues found on #42808.
The documentation on the trait was updated with such a restriction (they can't
panic) as well as some other words about the relative instability about
implementing a bullet-proof allocator.
Closes#42808
Stabilize more APIs for the 1.20.0 release
In addition to the few stabilizations that have already landed, this cleans up the remaining APIs that are in `final-comment-period` right now to be stable by the 1.20.0 release
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
Includes `alloc_zeroed` method that `RawVec` has come to depend on.
Exposed private `Layout::from_size_align` ctor to be `pub`, and added
explicit conditions for when it will panic (namely, when `align` is
not power-of-two, or if rounding up `size` to a multiple of `align`
overflows). Normalized all `Layout` construction to go through
`Layout::from_size_align`.
Addressed review feedback regarding `struct Layout` and zero-sized
layouts.
Restrict specification for `dealloc`, adding additional constraint
that the given alignment has to match that used to allocate the block.
(This is a maximally conservative constraint on the alignment. An open
question to resolve (before stabilization) is whether we can return to
a looser constraint such as the one previously specified.)
Split `fn realloc_in_place` into separate `fn grow_in_place` and `fn
shrink_in_place` methods, which have default impls that check against
usable_size for reuse. Make `realloc` default impl try `grow_in_place`
or `shrink_in_place` as appropriate before fallback on
alloc+copy+dealloc.
Drive-by: When reviewing calls to `padding_needed_for`, discovered
what I think was an over-conservative choice for its argument
alignment. Namely, in `fn extend`, we automatically realign the whole
resulting layout to satisfy both old (self) and new alignments. When
the old alignment exceeds the new, this means we would insert
unnecessary padding. So I changed the code to pass in `next.align`
instead of `new_align` to `padding_needed_for`.
Replaced ref to `realloc_in_place` with `grow_in_place`/`shrink_in_place`.
Revised docs replacing my idiosyncratic style of `fn foo` with just
`foo` when referring to the function or method `foo`.
(Alpha-renamed `Allocator` to `Alloc`.)
Post-rebased, added `Debug` derive for `allocator::Excess` to satisfy
`missing_debug_implementations`.
We've got a freshly minted beta compiler, let's update to use that on nightly!
This has a few other changes associated with it as well
* A bump to the rustc version number (to 1.19.0)
* Movement of the `cargo` and `rls` submodules to their "proper" location in
`src/tools/{cargo,rls}`. Now that Cargo workspaces support the `exclude`
option this can work.
* Updates of the `cargo` and `rls` submodules to their master branches.
* Tweak to the `src/stage0.txt` format to be more amenable for Cargo version
numbers. On the beta channel Cargo will bootstrap from a different version
than rustc (e.g. the version numbers are different), so we need different
configuration for this.
* Addition of `dev` as a readable key in the `src/stage0.txt` format. If present
then stage0 compilers are downloaded from `dev-static.rust-lang.org` instead
of `static.rust-lang.org`. This is added to accomodate our updated release
process with Travis and AppVeyor.
More methods for str boxes. (reduce Box<[u8]> ↔ Box<str> transmutes)
This is a follow-up to #41096 that adds safer methods for converting between `Box<str>` and `Box<[u8]>`. They're gated under a different feature from the `&mut str` methods because they may be too niche to include in public APIs, although having them internally helps reduce the number of transmutes the standard library uses.
What's added:
* `From<Box<str>> for Box<[u8]>`
* `<Box<str>>::into_boxed_bytes` (just calls `Into::into`)
* `alloc::str` (new module)
* `from_boxed_utf8` and `from_boxed_utf8_unchecked`, defined in `alloc:str`, exported in `collections::str`
* exports `from_utf8_mut` in `collections::str` (missed from previous PR)
this avoids parsing item attributes on each call to `item_attrs`, which takes
off 33% (!) of translation time and 50% (!) of trans-item collection time.
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.
make `alloc` and `collections` compilable for thumbv6m-none-eabi
by cfging away `alloc::Arc` and changing OOM to abort for this target
r? @alexcrichton
cc @thejpster