| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
Deprecate offset_to; switch core&alloc to using offset_from instead
Bonus: might make code than uses `.len()` on slice iterators faster
cc https://github.com/rust-lang/rust/issues/41079
|
|
Merge the std_unicode crate into the core crate
[The standard library facade](https://github.com/rust-lang/rust/issues/27783) has historically contained a number of crates with different roles, but that number has decreased over time. `rand` and `libc` have moved to crates.io, and [`collections` was merged into `alloc`](https://github.com/rust-lang/rust/pull/42648). Today we have `core` that applies everywhere, `std` that expects a full operating system, and `alloc` in-between that only requires a memory allocator (which can be provided by users)… and `std_unicode`, which doesn’t really have a reason to be separate anymore. It contains functionality based on Unicode data tables that can be large, but as long as relevant functions are not called the tables should be removed from binaries by linkers.
This deprecates the unstable `std_unicode` crate and moves all of its contents into `core`, replacing them with `pub use` reexports. The crate can be removed later. This also removes the `CharExt` trait (replaced with inherent methods in libcore) and `UnicodeStr` trait (merged into `StrExt`). There traits were both unstable and not intended to be used or named directly.
A number of new items are newly-available in libcore and instantly stable there, but only if they were already stable in libstd.
Fixes #49319.
|
|
|
|
|
|
And the UnicodeStr trait into StrExt
|
|
|
|
|
|
|
|
Use sort_by_cached_key where appropriate
A follow-up to https://github.com/rust-lang/rust/pull/48639, converting various slice sorting calls to `sort_by_cached_key` when the key functions are more expensive.
|
|
|
|
|
|
This permits easier iteration without having to worry about warnings
being denied.
Fixes #49517
|
|
|
|
Bump the bootstrap compiler to 1.26.0 beta
Holy cow that's a lot of `cfg(stage0)` removed and a lot of new stable language
features!
|
|
|
|
|
|
|
|
Holy cow that's a lot of `cfg(stage0)` removed and a lot of new stable language
features!
|
|
Rollup of 9 pull requests
Successful merges:
- #48658 (Add a generic CAS loop to std::sync::Atomic*)
- #49253 (Take the original extra-filename passed to a crate into account when resolving it as a dependency)
- #49345 (RFC 2008: Finishing Touches)
- #49432 (Flush executables to disk after linkage)
- #49496 (Add more vec![... ; n] optimizations)
- #49563 (add a dist builder to build rust-std components for the THUMB targets)
- #49654 (Host compiler documentation: Include private items)
- #49667 (Add more features to rust_2018_preview)
- #49674 (ci: Remove x86_64-gnu-incremental builder)
Failed merges:
|
|
Add more vec![... ; n] optimizations
vec![0; n], via implementations of SpecFromElem, has an optimization that uses with_capacity_zeroed instead of with_capacity, which will use calloc instead of malloc, and avoid an extra memset.
This PR adds the same optimization for ptr::null, ptr::null_mut, and None, when their in-memory representation is zeroes.
|
|
Stabilize attributes on generic parameters
Closes https://github.com/rust-lang/rust/issues/48848
|
|
|
|
|
|
Stabilize iterator methods in 1.27
- Closes #39480, feature `iter_rfind`
- `DoubleEndedIterator::rfind`
- Closes #44705, feature `iter_rfold`
- `DoubleEndedIterator::rfold`
- Closes #45594, feature `iterator_try_fold`
- `Iterator::try_fold`
- `Iterator::try_for_each`
- `DoubleEndedIterator::try_rfold`
|
|
Stabilize String::replace_range
Fixes #44643
|
|
Introduce Vec::resize_with method (see #41758)
In #41758, the libs team decided they preferred `Vec::resize_with` over `Vec::resize_default()`. Here is an implementation to get this moving forward.
I don't know what the removal process for `Vec::resize_default()` should be, so I've left it in place for now. Would be happy to follow up with its removal.
|
|
Add #[must_use] to a few standard library methods
Chosen to start a precedent of using it on ones that are potentially-expensive and where using it for side effects is particularly discouraged.
Discuss :)
```rust
warning: unused return value of `std::iter::Iterator::collect` which must be used: if you really need to exhaust the iterator, consider `.for_each(drop)` instead
--> $DIR/fn_must_use_stdlib.rs:19:5
|
LL | "1 2 3".split_whitespace().collect::<Vec<_>>();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
warning: unused return value of `std::borrow::ToOwned::to_owned` which must be used: cloning is often expensive and is not expected to have side effects
--> $DIR/fn_must_use_stdlib.rs:21:5
|
LL | "hello".to_owned();
| ^^^^^^^^^^^^^^^^^^^
warning: unused return value of `std::clone::Clone::clone` which must be used: cloning is often expensive and is not expected to have side effects
--> $DIR/fn_must_use_stdlib.rs:23:5
|
LL | String::from("world").clone();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
cc https://github.com/rust-lang/rust/issues/48926
|
|
|
|
Closes #22181, #27779
|
|
|
|
|
|
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.
|
|
Fixes #44643
|
|
Similarly to vec![ptr::null{,_mut}(); n] in previous change, this adds
the optimization for vec!['\0'; n].
|
|
vec![0; n], via implementations of SpecFromElem, has an optimization
that uses with_capacity_zeroed instead of with_capacity, which will use
calloc instead of malloc, and avoid an extra memset.
This adds the same optimization for vec![ptr::null(); n] and
vec![ptr::null_mut(); n], assuming their bit value is 0 (which is true
on all currently supported platforms).
This does so by adding an intermediate trait IsZero, which looks very
much like nonzero::Zeroable, but that one is on the way out, and doesn't
apply to pointers anyways.
Adding such a trait allows to avoid repeating the logic using
with_capacity_zeroed or with_capacity, or making the macro more complex
to support generics.
|
|
This helps with the specific problem described in #49541, obviously without
making any large change to how inlining works in the general case.
Everything involved in the conversions is made `#[inline]`, except for the
`<Vec<T>>::into_boxed_slice` entry point which is made `#[inline(always)]`
after checking that duplicating the function mentioned in the issue prevented
its inlining if I only annotate it with `#[inline]`.
For the record, that function was:
```rust
pub fn foo() -> Box<[u8]> {
vec![0].into_boxed_slice()
}
```
To help the inliner's job, we also hoist a `self.capacity() != self.len` check
in `<Vec<T>>::shrink_to_fit` and mark it as `#[inline]` too.
|
|
Bonus: might make code than uses `.len()` on slice iterators faster
|
|
Move the alloc::allocator module to core::heap
This is the `Alloc` trait and its dependencies.
|
|
Chosen to start a precedent of using it on ones that are potentially-expensive and where using it for side effects is particularly discouraged.
Discuss :)
|
|
Remove unnecessary use core::hash in liballoc/boxed.rs
It' only used for hash::Hasher, but Hasher is also imported.
|
|
Use f{32,64}::to_bits for is_zero test in vec::SpecFromElem
vec::SpecFromElem provides an optimization to use calloc to fill a Vec
when the element given to fill the Vec is represented by 0.
For floats, the test for that currently used is `x == 0. &&
x.is_sign_positive()`. When compiled in a standalone function, rustc
generates the following assembly:
```
xorps xmm1, xmm1
ucomisd xmm0, xmm1
setnp al
sete cl
and cl, al
movq rax, xmm0
test rax, rax
setns al
and al, cl
ret
```
A simpler test telling us whether the value is represented by 0, is
`x.to_bits() == 0`, which rustc compiles to:
```
movq rax, xmm0
test rax, rax
sete al
ret
```
Not that the test is hot in any way, but it also makes it clearer what
the intent in the rust code is.
|
|
This is the `Alloc` trait and its dependencies.
|
|
These unstable items are deprecated:
* The `std::collections::range::RangeArgument` reexport
* The `std::collections::range` module.
|
|
The stable reexport `std::collections::Bound` is now deprecated.
Another deprecated reexport could be added in `alloc`,
but that crate is unstable.
|
|
It' only used for hash::Hasher, but Hasher is also imported.
|
|
vec::SpecFromElem provides an optimization to use calloc to fill a Vec
when the element given to fill the Vec is represented by 0.
For floats, the test for that currently used is `x == 0. &&
x.is_sign_positive()`. When compiled in a standalone function, rustc
generates the following assembly:
```
xorps xmm1, xmm1
ucomisd xmm0, xmm1
setnp al
sete cl
and cl, al
movq rax, xmm0
test rax, rax
setns al
and al, cl
ret
```
A simpler test telling us whether the value is represented by 0, is
`x.to_bits() == 0`, which rustc compiles to:
```
movq rax, xmm0
test rax, rax
sete al
ret
```
Not that the test is hot in any way, but it also makes it clearer what
the intent in the rust code is.
|
|
Clarify "length" wording in `Vec::with_capacity`.
Fixes https://github.com/rust-lang/rust/issues/49448.
|
|
Implement `shrink_to` method on collections
Fixes #49385
|