| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Only the "first" iterator is actually set `None` when exhausted,
depending on whether you iterate forward or backward. This restores
behavior similar to the former `ChainState`, where it would transition
from `Both` to `Front`/`Back` and only continue from that side.
However, if you mix directions, then this may still set both sides to
`None`, totally fusing the iterator.
|
|
Stabilize most common subset of alloc_layout_extras
Tracking issue: https://github.com/rust-lang/rust/issues/55724
Specifically, this stabilizes:
```rust
pub fn Layout::align_to(&self, align: usize) -> Result<Layout, LayoutErr>;
pub fn Layout::pad_to_align(&self) -> Layout;
pub fn Layout::extend(&self, next: Layout) -> Result<(Layout, usize), LayoutErr>;
pub fn Layout::array<T>(n: usize) -> Result<Layout, LayoutErr>;
```
Methods that are tracked by #55724 but are not stabilized here:
```rust
pub fn Layout::padding_needed_for(&self, align: usize) -> usize;
pub fn Layout::repeat(&self, n: usize) -> Result<(Layout, usize), LayoutErr>;
pub fn Layout::repeat_packed(&self, n: usize) -> Result<Layout, LayoutErr>;
pub fn Layout::extend_packed(&self, next: Layout) -> Result<Layout, LayoutErr>;
```
Combined, these stabilized functions allow code to construct and manipulate `repr(C)` layouts while letting the standard library handle correctness in the face of edge cases. For example use cases, consider the usage in [hashbrown](https://github.com/Amanieu/hashbrown/blob/2f2af1d/src/raw/mod.rs#L143), [crossbeam-skiplist](https://github.com/crossbeam-rs/crossbeam-skiplist/blob/master/src/base.rs#L99), [pointer-utils/slice-dst](https://github.com/CAD97/pointer-utils/blob/92aeefeed9399f28d1b1654b63f8dcbe1242d8d4/crates/slice-dst/src/layout_polyfill.rs), and of course the standard library itself.
Providing a higher-level API such as `Layout::repr_c<const N: usize>(fields: [Layout; N]) -> Result<(Layout, [usize; N]), LayoutErr>` is blocked on const generics, which are a ways off. Providing an API that doesn't provide offsets would be quite suboptimal, as the reason for calculating the layout like this rather than `Layout::new` is to get the field offsets.
The primary issue with the current API is having to call `.pad_to_align()` to match the layout of a `repr(C)` struct. However, I think this is not just a (failing? limitation?) of the API, but rather intrinsic complexity. While all Rust-defined types have size==stride, and probably will for the foreseeable future, there is no inherent reason why this is a limitation of all allocations. As such, the `Layout` manipulation APIs shouldn't impose this limitation, and instead the higher level api of `repr_c` (or just plain old using `Layout::new`) can make keeping it simple.
cc @matklad r? @rust-lang/libs
|
|
|
|
Co-Authored-By: Amanieu d'Antras <amanieu@gmail.com>
|
|
Update pattern docs.
A few changes to help clarify string pattern usage:
* Add some examples and stability information in the `pattern` module.
* Fixes the links at https://doc.rust-lang.org/std/str/pattern/ because intra-doc-links don't work with re-exported modules (#65983 I think?).
* Consistently use the same phrasing for `str` methods taking a pattern.
* Also mention that array of `char` is also accepted.
When `Pattern` is stabilized, the phrasing in the `str` methods can be updated to be more general to reflect the exact behavior. I'm reluctant to do this now because the stability story for `Pattern` is uncertain. It may perhaps look something like:
> The pattern can be any type that implements the [`Pattern`] trait. Notable examples are `&str`, [`char`], arrays of [`char`], or functions or closures that determines if a character matches. Additional libraries might provide more complex patterns like regular expressions.
This is complicated because methods like `trim_matches` have bounds, which for example don't support `str`, so those methods may need more elaboration.
|
|
Deprecate the asm! macro in favor of llvm_asm!
Since we will be changing the syntax of `asm!` soon, deprecate it and encourage people to use `llvm_asm!` instead (which preserves the old syntax). This will avoid breakage when `asm!` is changed.
RFC: https://github.com/rust-lang/rfcs/pull/2843
|
|
|
|
Add example in the alternative in std::mem::transmute docs
It is safer to use `from_ne_bytes` to convert raw bytes to type like u32. #71187
|
|
It is safer to use `from_ne_bytes` to convert raw bytes to type like u32.
|
|
|
|
big-O notation: parenthesis for function calls, explicit multiplication
I saw `O(n m log n)` in the docs and found that really hard to parse. In particular, I don't think we should use blank space as syntax for *both* multiplication and function calls, that is just confusing.
This PR makes both multiplication and function calls explicit using Rust-like syntax. If you prefer, I can also leave one of them implicit, but I believe explicit is better here.
While I was at it I also added backticks consistently.
|
|
Fix typo in Default trait docs: Provides -> Provide
An earlier commit (99ed06e) accidentally changed this paragraph from the original, imperative `Provide` to the present tense `Provides`. The latter is indeed the standard for Rustdoc comments relating to a function or method, but this snippet is introducing the `Default` trait in general terms and not talking about any particular function. I believe this change was likely made in error and should be reverted.
|
|
Dogfood or_patterns in the standard library
We can start using `or_patterns` in the standard library as a step toward stabilization.
cc #54883 @Centril
|
|
Hides default fns inside Fuse impl to avoid exposing it to any crate
Fixes #70796
@cuviper I've added some default, private traits to do the job for us. If required, I can expose them to a specific visibility if you want to call these functions for #70332
r? @cuviper
|
|
An earlier commit (99ed06e) accidentally changed this paragraph from the
original, imperative "Provide" to the present tense "Provides". The
latter is indeed the standard for Rustdoc comments relating to a
function or method, but this snippet is introducing the Default trait in
general terms and not talking about any particular function. I believe
this change was likely made in error and should be reverted.
|
|
Co-Authored-By: Ralf Jung <post@ralfj.de>
|
|
|
|
Remove a stack frame from .await calls
The stack frames when `.await`ing one async fn from another currently look like this:
```
12: foo::b::{{closure}}
at src/main.rs:2
13: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66
14: core::future::poll_with_context
at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84
15: foo::a::{{closure}}
at src/main.rs:6
```
Since the move away from using TLS to pass the Context around, it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame, but that seems significantly harder to deal with.
It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Tighten time complexity on the doc of sort_by_key
Fixes #71132
|
|
ptr: introduce len() method on raw slices
It is already possible to extract the pointer part of a raw slice by a
simple cast, but retrieving the length is not possible without relying
on the representation of the raw slice when it is not valid to convert
the raw slice into a slice reference (i.e. the pointer is null or
unaligned).
~Introduce a new function ptr::slice_len() to add this missing feature.~
Introduce a len() method on raw slices to add this missing feature.
|
|
|
|
It is already possible to extract the pointer part of a raw slice by a
simple cast, but retrieving the length is not possible without relying
on the representation of the raw slice when it is not valid to convert
the raw slice into a slice reference (i.e. the pointer is null or
unaligned).
Introduce a len() method on raw slices to add this missing feature.
|
|
|
|
|
|
It's been gone since #23945, before Rust 1.0. The former wrapping
semantics have also been available as inherent methods for a long time
now. There's no reason to keep this unused macro around.
|
|
|
|
|
|
Remove the UnicodeVersion struct containing
major, minor and update fields and replace it with
a 3-tuple containing the version number.
As the value of each field is limited to 255
use u8 to store them.
|
|
Removed unnecessarry empty impls.
Moved code to organise it better
|
|
Implement Chain with Option fuses
The iterators are now "fused" with `Option` so we don't need separate state to track which part is already exhausted, and we may also get niche layout for `None`. We don't use the real `Fuse` adapter because its specialization for `FusedIterator` unconditionally descends into the iterator, and that could be expensive to keep revisiting stuff like nested chains. It also hurts compiler performance to add more iterator layers to `Chain`.
This change was inspired by the [proposal](https://internals.rust-lang.org/t/proposal-implement-iter-chain-using-fuse/12006) on the internals forum. This is an alternate to #70332, directly employing some of the same `Fuse` optimizations as #70366 and #70750.
r? @scottmcm
|
|
|
|
FuseExactSizeIteratorImpl to avoid exposing default functions outside of the current crate.
|
|
|
|
|
|
|
|
The iterators are now "fused" with `Option` so we don't need separate
state to track which part is already exhausted, and we may also get
niche layout for `None`. We don't use the real `Fuse` adapter because
its specialization for `FusedIterator` unconditionally descends into the
iterator, and that could be expensive to keep revisiting stuff like
nested chains. It also hurts compiler performance to add more iterator
layers to `Chain`.
|
|
|
|
|
|
|
|
Stop importing the float modules in documentation
Follow up to #69860. I realized I had not searched for and fixed this for the float values. So with this PR they also use the associated constants instead of the module level constants.
For the documentation where it also was using the `consts` submodule I opted to change it to import that directly. This becomes more in line with how other docs that use the `consts` submodule looks. And it also makes it so there are not two `f32` or `f64` things in the current namespace (both the module and the primitive type) and then hopefully confusing documentation readers less.
r? @dtolnay
|
|
Match options directly in the Fuse implementation
Rather than using `as_ref()`, `as_mut()`, and `?`, we can use `match` directly to save a lot of generated code. This was mentioned as a possibility in https://github.com/rust-lang/rust/pull/70366#issuecomment-603462546, and I found that it had a very large impact on #70332 using `Fuse` within `Chain`. Let's evaluate this change on its own first.
|
|
Don't import integer and float modules, use assoc consts
Stop importing the standard library integer and float modules to reach the `MIN`, `MAX` and other constants. They are available directly on the primitive types now.
This PR is a follow up of #69860 which made sure we use the new constants in documentation.
This type of change touches a lot of files, and previously all my assoc int consts PRs had collisions and were accepted only after a long delay. So I'd prefer to do it in smaller steps now. Just removing these imports seem like a good next step.
r? @dtolnay
|
|
docs: make the description of Result::map_or more clear
The documentation of [`Result::map_or`](https://doc.rust-lang.org/std/result/enum.Result.html#method.map_or) is very unclear and confusing, probably because it was copied straight from [`Option::map_or`](https://doc.rust-lang.org/std/option/enum.Option.html#method.map_or) and someone forgot to adapt it for Result.
|
|
|
