| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Document unsafety in core::{panicking, alloc::layout, hint, iter::adapters::zip}
Helps with #66219.
r? @Mark-Simulacrum do you want to continue reading safety comments? :D
|
|
Stabilize UNICODE_VERSION (feature unicode_version)
Tracking issue: #49726
r? @sfackler
#71020 changed the definition of `UNICODE_VERSION` just yesterday from a struct to a tuple. Maybe you want to wait some more before stabilizing this constant, on the other hand this is a very small and simple addition.
CC @behnam @SimonSapin @Serentty
|
|
Document unsafety in core::{option, hash}
Helps with #66219.
I think that the part that will need reviewing the most is the `hash/sip.rs` file.
r? @LukasKalbertodt (or someone else from the libs team)
|
|
iter::adapters::zip}`
|
|
Co-Authored-By: Mark-Simulacrum <mark.simulacrum@gmail.com>
|
|
Changed raw pointer name from ptr to raw_pointer to avoid confusion with
the `use std::ptr` statement a few lines above. This way the crate name
and pointer name are well differenciated.
|
|
Fix doc links
This fixes a few doc links which were causing `cargo doc` to fail when using `--document-private-items --document-hidden-items` on libstd. Most of the fixes are just escaping '[' and ']' characters in doc comments, and one change actually fixes a doc link.
|
|
Only use read_unaligned in transmute_copy if necessary
I've noticed that this causes LLVM to generate poor code on targets that don't support unaligned memory accesses.
|
|
Add a "by reference" adaptor for `AllocRef`
Fixes rust-lang/wg-allocators#53
r? @Amanieu
|
|
Don't fuse Chain in its second iterator
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.
Fixes #71375
r? @scottmcm
|
|
|
|
Co-authored-by: Mark-Simulacrum <mark.simulacrum@gmail.com>
|
|
|
|
|
|
|
|
Inline some function docs in `core::ptr`
Resolves #64539.
|
|
The feature will become stable in Rust 1.45.
Noted that the value of UNICODE_VERSION is expected to change.
|
|
|
|
|
|
Implement `Copy` for `AllocErr`
r? @Amanieu
|
|
Lint must_use on mem::replace
This adds a hint on `mem::replace`, "if you don't need the old value,
you can just assign the new value directly". This is in similar spirit
to the `must_use` on `ManuallyDrop::take`.
|
|
|
|
|
|
Use assoc int consts3
Define module level int consts with associated constants instead of `min_value()` and `max_value()`. So the code become consistent with what the docs recommend etc. Seems natural.
Also remove the last usages of the int module constants from this repo (except src/test/ directory which I have still not really done anything in). Some places were missed in the previous PRs because the code uses `crate::<IntTy>` to reach the constants.
This is a continuation of #70857
r? @dtolnay
|
|
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.
|
|
|
|
This adds a hint on `mem::replace`, "if you don't need the old value,
you can just assign the new value directly". This is in similar spirit
to the `must_use` on `ManuallyDrop::take`.
|
|
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.
|
|
|
|
|
|
|
