| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
avoid transmuting Box when we can just cast raw pointers instead
Always better to avoid a transmute, in particular when the layout assumptions it is making are not clearly documented. :)
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
[nit] Fix a comment typo.
|
|
|
|
|
|
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
|
|
* remove `impl Provider for Error`
* rename `Demand` to `Request`
* update docstrings to focus on the conceptual API provided by `Request`
* move `core::any::{request_ref, request_value}` functions into `core::error`
* move `core::any::tag`, `core::any::Request`, an `core::any::TaggedOption` into `core::error`
* replace `provide_any` feature name w/ `error_generic_member_access`
* move `core::error::request_{ref,value} tests into core::tests::error module
* update unit and doc tests
|
|
|
|
Fix documentation of impl From<Vec<T>> for Rc<[T]>
The example in the documentation of `impl From<Vec<T>> for <Rc<[T]>` is irrelevant (likely was copied from `impl From<Box<T>> for <Rc<T>`). I suggest taking corresponding example from the documentation of `Arc` and replacing `Arc` with `Rc`.
|
|
Avoid using `ptr::Unique` in `LinkedList` code
Addresses a [comment](https://github.com/rust-lang/rust/pull/103093#discussion_r1268506747) by `@RalfJung` about avoiding use of `core::ptr::Unique` in the standard library.
|
|
str.rs: remove "Basic usage" text
Only one example is given
|
|
string.rs: remove "Basic usage" text
Only a single example is given
|
|
Add the attribute to standard library functions that
are guaranteed to never return null pointers, as their
originating data wouldn't allow it.
|
|
It lints against features that are inteded to be internal to the
compiler and standard library. Implements MCP #596.
We allow `internal_features` in the standard library and compiler as those
use many features and this _is_ the standard library from the "internal to the compiler and
standard library" after all.
Marking some features as internal wasn't exactly the most scientific approach, I just marked some
mostly obvious features. While there is a categorization in the macro,
it's not very well upheld (should probably be fixed in another PR).
We always pass `-Ainternal_features` in the testsuite
About 400 UI tests and several other tests use internal features.
Instead of throwing the attribute on each one, just always allow them.
There's nothing wrong with testing internal features^^
|
|
|
|
Only one example is given
|
|
Only a single example is given
|
|
Stabilize const-weak-new
This is a fairly uncontroversial library stabilization, so I'm going ahead and proposing it to ride the trains to stable.
This stabilizes the following APIs, which are defined to be non-allocating constructors.
```rust
// alloc::rc
impl<T> Weak<T> {
pub const fn new() -> Weak<T>;
}
// alloc::sync
impl<T> Weak<T> {
pub const fn new() -> Weak<T>;
}
```
Closes #95091
``@rustbot`` modify labels: +needs-fcp
|
|
Bump its stabilization version several times along
the way to accommodate changes in release processes.
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
Co-authored-by: Trevor Gross <t.gross35@gmail.com>
|
|
|
|
Documentation: Fix Stilted Language in Vec->Indexing
Problem
Language in the Vec->Indexing documentation sounds stilted due to incorrect word ordering: "... type allows to access values by index."
Solution
Reorder words in the Vec->Indexing documentation to flow better: "... type allows access to values by index." The phrase "allows access to" also matches other existing documentation.
|
|
Rollup of 3 pull requests
Successful merges:
- #112151 (Clarify behavior of inclusive bounds in BTreeMap::{lower,upper}_bound)
- #113512 (Updated lines doc to include trailing carriage return note)
- #114203 (Effects: don't print `host` param in diagnostics)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Clarify behavior of inclusive bounds in BTreeMap::{lower,upper}_bound
It wasn’t quite clear to me how these methods would interpret inclusive bounds so I added examples for those.
|
|
Remove redundant example of `BTreeSet::iter`
The usage and that `Values returned by the iterator are returned in ascending order` are already demonstrated by the other example and the description, so I removed the useless one.
|
|
Problem
Language in the Vec->Indexing documentation sounds stilted due to
incorrect word ordering: "... type allows to access values by index."
Solution
Reorder words in the Vec->Indexing documentation to flow better:
"... type allows access to values by index." The phrase "allows access to"
also matches other existing documentation.
|
|
Not useful, for there is just a single example
|
|
Signed-off-by: TennyZhuang <zty0826@gmail.com>
|
|
internal buffer
|
|
Hide `ToString` implementations that specialize the default one
The status quo is highly confusing, since the overlap is not apparent, and specialization is not a feature of Rust. This change addresses #87545; I'm not certain if it closes/fixes it entirely, since that issue might also be tracking the question of a *general* solution for hiding the documentation for specializing impls automatically.
Before
After
|
|
|
|
|
|
The status quo is highly confusing, since the overlap is not apparent,
and specialization is not a feature of Rust. This addresses #87545;
I'm not certain if it closes it, since that issue might also be trackign
a *general* solution for hiding specializing impls automatically.
|
|
Rollup of 6 pull requests
Successful merges:
- #112490 (Remove `#[cfg(all())]` workarounds from `c_char`)
- #113252 (Update the tracking issue for `const_cstr_from_ptr`)
- #113442 (Allow limited access to `OsString` bytes)
- #113876 (fix docs & example for `std::os::unix::prelude::FileExt::write_at`)
- #113898 (Fix size_hint for EncodeUtf16)
- #113934 (Multibyte character removal in String::pop and String::remove doctests)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove lifetime bound for A for `impl Extend<&'a T> for Vec<T, A>`.
The lifetime of the references being copied from is unrelated to the allocator.
Compare with [`impl<'a, T: 'a + Copy, A: Allocator> Extend<&'a T> for VecDeque<T, A>`](https://doc.rust-lang.org/alloc/collections/vec_deque/struct.VecDeque.html#impl-Extend%3C%26'a+T%3E-for-VecDeque%3CT,+A%3E) which does not have the `A: 'a` bound already.
Since `Allocator` is unstable, the only possible `A` on stable is `Global`, and `Global: 'static`, so this change is not (should not be) observable on stable (or without `#![feature(allocator_api)]`). [This is observable on nightly](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=8c4aa166c6116a90593d2934d30cfeb3).
|
|
doctests
|
|
|
|
|
|
Add support for allocators in `Rc` & `Arc`
Adds the ability for `std::rc:Rc`, `std::rc::Weak`, `std::sync::Arc`, and `std::sync::Weak` to live in custom allocators
|
|
|
|
Rename VecDeque's `rotate_left` and `rotate_right` parameters
This pull request introduces a modification to the `VecDeque` collection, specifically the `rotate_left` and `rotate_right` functions, by renaming the parameter associated with these functions.
The rationale behind this change is to provide clearer and more consistent naming for the parameter that specifies the number of places to rotate the double-ended queue. By using `n` as the parameter name in both functions, it becomes easier to understand and remember the purpose of the parameter.
|
|
Eliminate ZST allocations in `Box` and `Vec`
This PR fixes 2 issues with `Box` and `RawVec` related to ZST allocations. Specifically, the `Allocator` trait requires that:
- If you allocate a zero-sized layout then you must later deallocate it, otherwise the allocator may leak memory.
- You cannot pass a ZST pointer to the allocator that you haven't previously allocated.
These restrictions exist because an allocator implementation is allowed to allocate non-zero amounts of memory for a zero-sized allocation. For example, `malloc` in libc does this.
Currently, ZSTs are handled differently in `Box` and `Vec`:
- `Vec` never allocates when `T` is a ZST or if the vector capacity is 0.
- `Box` just blindly passes everything on to the allocator, including ZSTs.
This causes problems due to the free conversions between `Box<[T]>` and `Vec<T>`, specifically that ZST allocations could get leaked or a dangling pointer could be passed to `deallocate`.
This PR fixes this by changing `Box` to not allocate for zero-sized values and slices. It also fixes a bug in `RawVec::shrink` where shrinking to a size of zero did not actually free the backing memory.
|
|
|
|
|
|
|
|
|
