| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fixes #25622.
|
|
|
|
|
|
|
|
Using regular pointer arithmetic to iterate collections of zero-sized types
doesn't work, because we'd get the same pointer all the time. Our
current solution is to convert the pointer to an integer, add an offset
and then convert back, but this inhibits certain optimizations.
What we should do instead is to convert the pointer to one that points
to an i8*, and then use a LLVM GEP instructions without the inbounds
flag to perform the pointer arithmetic. This allows to generate pointers
that point outside allocated objects without causing UB (as long as you
don't dereference them), and it wraps around using two's complement,
i.e. it behaves exactly like the wrapping_* operations we're currently
using, with the added benefit of LLVM being able to better optimize the
resulting IR.
|
|
Add the repeating form of the vec macro
Remove unneeded literal annotations.
Use more conventional variable names.
|
|
This commit is an implementation of [RFC 1066][rfc] where the conclusion was
that leaking a value is a safe operation in Rust code, so updating the signature
of this function follows suit.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1066-safe-mem-forget.md
Closes #25186
|
|
This commit is an implementation of [RFC 1066][rfc] where the conclusion was
that leaking a value is a safe operation in Rust code, so updating the signature
of this function follows suit.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1066-safe-mem-forget.md
Closes #25186
|
|
Ideally this trait implementation would be unstable, requiring crates to opt-in
if they would like the functionality, but that's not currently how stability
works so the implementation needs to be removed entirely.
This may come back at a future date, but for now the conservative option is to
remove it.
[breaking-change]
|
|
This commit does two things: it adds an example for indexing vectors, and it changes the \"Examples\" section to use full sentences.
This change was spurred by someone in the #rust IRC channel asking if there was a `.set()` method for changing the `i`-th value of a vector (they had missed that `Vec` implements `IndexMut`, which is easy to do if you're not aware of that trait).
|
|
This changes the std::vec module docs to use full sentences. It also adds an example
for indexing vectors.
|
|
|
|
These implementations were intended to be unstable, but currently the stability
attributes cannot handle a stable trait with an unstable `impl` block. This
commit also audits the rest of the standard library for explicitly-`#[unstable]`
impl blocks. No others were removed but some annotations were changed to
`#[stable]` as they're defacto stable anyway.
One particularly interesting `impl` marked `#[stable]` as part of this commit
is the `Add<&[T]>` impl for `Vec<T>`, which uses `push_all` and implicitly
clones all elements of the vector provided.
Closes #24791
|
|
|
|
Implement Vec::drain(\<range type\>) from rust-lang/rfcs#574, tracking issue #23055.
This is a big step forward for vector usability. This is an introduction of an API for removing a range of *m* consecutive elements from a vector, as efficently as possible.
New features:
- Introduce trait `std::collections::range::RangeArgument` implemented by all four built-in range types.
- Change `Vec::drain()` to use `Vec::drain<R: RangeArgument>(R)`
Implementation notes:
- Use @Gankro's idea for memory safety: Use `set_len` on the source vector when creating the iterator, to make sure that the part of the vector that will be modified is unreachable. Fix up things in Drain's destructor — but even if it doesn't run, we don't expose any moved-out-from slots of the vector.
- This `.drain<R>(R)` very close to how it is specified in the RFC.
- Introduced as unstable
- Drain reuses the slice iterator — copying and pasting the same iterator pointer arithmetic again felt very bad
- The `usize` index as a range argument in the RFC is not included. The ranges trait would have to change to accomodate it.
Please help me with:
- Name and location of the new ranges trait.
- Design of the ranges trait
- Understanding Niko's comments about variance (Note: for a long time I was using a straight up &mut Vec in the iterator, but I changed this to permit reusing the slice iterator).
Previous PR and discussion: #23071
|
|
Old `.drain()` on vec is performed using `.drain(..)` now.
`.drain(range)` is unstable and under feature(collections_drain)
[breaking-change]
|
|
|
|
Improve example for as_string and add example for as_vec
Provide a better example of `as_string` / `DerefString`'s unique capabilities.
Use an example where (for an unspecified reason) you need a &String, and
show how `as_string` solves the problem without needing an allocation.
|
|
|
|
|
|
|
|
|
|
Conflicts:
src/libcore/result.rs
|
|
Cleaning out more deprecated items
|
|
This is an implementation of [RFC 1030][rfc] which adds these traits to the
prelude and additionally removes all inherent `into_iter` methods on collections
in favor of the trait implementation (which is now accessible by default).
[rfc]: https://github.com/rust-lang/rfcs/pull/1030
This is technically a breaking change due to the prelude additions and removal
of inherent methods, but it is expected that essentially no code breaks in
practice.
[breaking-change]
Closes #24538
|
|
|
|
Right now, if the user requests to increase the vector size via reserve() or push_back() and the request brings the attempted memory above usize::MAX, we panic.
With this change there is only a panic if the minimum requested memory that could meet the requirement is above usize::MAX- otherwise it simply requests its largest capacity possible, usize::MAX.
|
|
with "let" when building on stage0. So change the error
message to a static const.
|
|
less confusing. Since 0 is the smallest number possible for usize, it doesn't make sense to mention it if it's already included, and it should be more clear that the length of the vector is a valid index with the new wording.
|
|
This was brought up in IRC by a confused reader.
|
|
This is a deprecated attribute that is slated for removal, and it also affects
all implementors of the trait. This commit removes the attribute and fixes up
implementors accordingly. The primary implementation which was lost was the
ability to compare `&[T]` and `Vec<T>` (in that order).
This change also modifies the `assert_eq!` macro to not consider both directions
of equality, only the one given in the left/right forms to the macro. This
modification is motivated due to the fact that `&[T] == Vec<T>` no longer
compiles, causing hundreds of errors in unit tests in the standard library (and
likely throughout the community as well).
Closes #19470
[breaking-change]
|
|
* The `io::Seek` trait.
* The `Iterator::{partition, unsip}` methods.
* The `Vec::into_boxed_slice` method.
* The `LinkedList::append` method.
* The `{or_insert, or_insert_with` methods in the `Entry` APIs.
r? @alexcrichton
|
|
Conflicts:
src/libcollectionstest/fmt.rs
src/libcollectionstest/lib.rs
src/libcollectionstest/str.rs
src/libcore/error.rs
src/libstd/fs.rs
src/libstd/io/cursor.rs
src/libstd/os.rs
src/libstd/process.rs
src/libtest/lib.rs
src/test/run-pass-fulldeps/compiler-calls.rs
|
|
* Marks `#[stable]` the contents of the `std::convert` module.
* Added methods `PathBuf::as_path`, `OsString::as_os_str`,
`String::as_str`, `Vec::{as_slice, as_mut_slice}`.
* Deprecates `OsStr::from_str` in favor of a new, stable, and more
general `OsStr::new`.
* Adds unstable methods `OsString::from_bytes` and `OsStr::{to_bytes,
to_cstring}` for ergonomic FFI usage.
[breaking-change]
r? @alexcrichton
|
|
This commit cleans out a large amount of deprecated APIs from the standard
library and some of the facade crates as well, updating all users in the
compiler and in tests as it goes along.
|
|
|
|
* The `io::Seek` trait, and `SeekFrom` enum.
* The `Iterator::{partition, unsip}` methods.
* The `Vec::into_boxed_slice` method.
* The `LinkedList::append` method.
* The `{or_insert, or_insert_with` methods in the `Entry` APIs.
|
|
This is a deprecated attribute that is slated for removal, and it also affects
all implementors of the trait. This commit removes the attribute and fixes up
implementors accordingly. The primary implementation which was lost was the
ability to compare `&[T]` and `Vec<T>` (in that order).
This change also modifies the `assert_eq!` macro to not consider both directions
of equality, only the one given in the left/right forms to the macro. This
modification is motivated due to the fact that `&[T] == Vec<T>` no longer
compiles, causing hundreds of errors in unit tests in the standard library (and
likely throughout the community as well).
cc #19470
[breaking-change]
|
|
* Marks `#[stable]` the contents of the `std::convert` module.
* Added methods `PathBuf::as_path`, `OsString::as_os_str`,
`String::as_str`, `Vec::{as_slice, as_mut_slice}`.
* Deprecates `OsStr::from_str` in favor of a new, stable, and more
general `OsStr::new`.
* Adds unstable methods `OsString::from_bytes` and `OsStr::{to_bytes,
to_cstring}` for ergonomic FFI usage.
[breaking-change]
|
|
|
|
This functions swaps the order of arguments to a few functions that previously
took (output, input) parameters, but now take (input, output) parameters (in
that order).
The affected functions are:
* ptr::copy
* ptr::copy_nonoverlapping
* slice::bytes::copy_memory
* intrinsics::copy
* intrinsics::copy_nonoverlapping
Closes #22890
[breaking-change]
|
|
|
|
try to get capacity for usize::MAX
|
|
|
|
for only half of the maximum size available on the architecture. This
allows vectors to keep expanding with those two methods until the amount
of bytes exceeds usize.
|
|
Pretty much what it says on the tin.
|
|
|
|
Conflicts:
src/libcollections/vec.rs
|
|
This is technically a breaking change as it deprecates and unstables some previously stable apis that were missed in the last round of deprecations.
[breaking change]
|
|
|
