| Age | Commit message (Collapse) | Author | Lines |
|
Ok, I can't use `std` in doc-links, only in doc-tests. Try 7...
|
|
of DoubleEndedIterator::next_back for types in liballoc and libcore.
Provided that the iterator has finite length and does not trigger user-provided code, this is safe.
What follows is a full list of the DoubleEndedIterators in liballoc/libcore and whether this optimization is safe, and if not, why not.
src/liballoc/boxed.rs
Box: Pass through to avoid defeating optimization of the underlying DoubleIterator implementation. This has no correctness impact.
src/liballoc/collections/binary_heap.rs
Iter: Pass through to avoid defeating optimizations on slice::Iter
IntoIter: Not safe, changes Drop order
Drain: Not safe, changes Drop order
src/liballoc/collections/btree/map.rs
Iter: Safe to call next_back, invokes no user defined code.
IterMut: ditto
IntoIter: Not safe, changes Drop order
Keys: Safe to call next_back, invokes no user defined code.
Values: ditto
ValuesMut: ditto
Range: ditto
RangeMut: ditto
src/liballoc/collections/btree/set.rs
Iter: Safe to call next_back, invokes no user defined code.
IntoIter: Not safe, changes Drop order
Range: Safe to call next_back, invokes no user defined code.
src/liballoc/collections/linked_list.rs
Iter: Safe to call next_back, invokes no user defined code.
IterMut: ditto
IntoIter: Not safe, changes Drop order
src/liballoc/collections/vec_deque.rs
Iter: Safe to call next_back, invokes no user defined code.
IterMut: ditto
IntoIter: Not safe, changes Drop order
Drain: ditto
src/liballoc/string.rs
Drain: Safe because return type is a primitive (char)
src/liballoc/vec.rs
IntoIter: Not safe, changes Drop order
Drain: ditto
Splice: ditto
src/libcore/ascii.rs
EscapeDefault: Safe because return type is a primitive (u8)
src/libcore/iter/adapters/chain.rs
Chain: Not safe, invokes user defined code (Iterator impl)
src/libcore/iter/adapters/flatten.rs
FlatMap: Not safe, invokes user defined code (Iterator impl)
Flatten: ditto
FlattenCompat: ditto
src/libcore/iter/adapters/mod.rs
Rev: Not safe, invokes user defined code (Iterator impl)
Copied: ditto
Cloned: Not safe, invokes user defined code (Iterator impl and T::clone)
Map: Not safe, invokes user defined code (Iterator impl + closure)
Filter: ditto
FilterMap: ditto
Enumerate: Not safe, invokes user defined code (Iterator impl)
Skip: ditto
Fuse: ditto
Inspect: ditto
src/libcore/iter/adapters/zip.rs
Zip: Not safe, invokes user defined code (Iterator impl)
src/libcore/iter/range.rs
ops::Range: Not safe, changes Drop order, but ALREADY HAS SPECIALIZATION
ops::RangeInclusive: ditto
src/libcore/iter/sources.rs
Repeat: Not safe, calling last should iloop.
Empty: No point, iterator is at most one item long.
Once: ditto
OnceWith: ditto
src/libcore/option.rs
Item: No point, iterator is at most one item long.
Iter: ditto
IterMut: ditto
IntoIter: ditto
src/libcore/result.rs
Iter: No point, iterator is at most one item long
IterMut: ditto
IntoIter: ditto
src/libcore/slice/mod.rs
Split: Not safe, invokes user defined closure
SplitMut: ditto
RSplit: ditto
RSplitMut: ditto
Windows: Safe, already has specialization
Chunks: ditto
ChunksMut: ditto
ChunksExact: ditto
ChunksExactMut: ditto
RChunks: ditto
RChunksMut: ditto
RChunksExact: ditto
RChunksExactMut: ditto
src/libcore/str/mod.rs
Chars: Safe, already has specialization
CharIndices: ditto
Bytes: ditto
Lines: Safe to call next_back, invokes no user defined code.
LinesAny: Deprecated
Everything that is generic over P: Pattern: Not safe because Pattern invokes user defined code.
SplitWhitespace: Safe to call next_back, invokes no user defined code.
SplitAsciiWhitespace: ditto
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove `FnBox`
Remove `FnBox` since we now have `Box<dyn FnOnce>`.
Closes https://github.com/rust-lang/rust/issues/28796.
r? @cramertj
|
|
As suggested in https://github.com/rust-lang/rust/pull/60340#issuecomment-493681032
|
|
|
|
r=sfackler
SliceConcatExt::connect defaults to calling join
It makes sense to default a deprecated method to the new one. Precedence example is `Error::cause` defaults to calling `Error::source`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
make `Weak::ptr_eq`s into methods
This makes the `Weak::ptr_eq`s associated function into methods. There's no reason for methods on `Weak`s to be associated functions, as there is no `Dered` thus no possibility of a collision. Also: methods can be called using the associated function syntax.
follow up on https://github.com/rust-lang/rust/pull/55987
[Tracking issue for weak_ptr_eq](https://github.com/rust-lang/rust/issues/55981)
|
|
|
|
|
|
Add some Vec <-> VecDeque documentation
These are more than just `.into_iter().collect()`, so talk about some of their nuances.
For VecDeque -> Vec I'm trying to intentionally not write a guarantee for people making their own `Vec`s, since the rules are more complicated than I think we want to commit to forever.
The "Vec -> VecDeque doesn't reallocate" guarantee seems reasonable, though. (And I'm intentionally ambiguous about when it's O(1) instead of O(n).)
|
|
Because Weak doesn't Deref, so there's no reason for them to be only
associated methods.
|
|
docs: Use String in Rc::into_raw examples
It is unclear if accessing an integer after `drop_in_place` has been
called on it is undefined behaviour or not, as demonstrated by the
discussion in
https://github.com/rust-lang/rust/pull/60766#pullrequestreview-243414222.
Avoid these uncertainties by using String which frees memory in its
`drop_in_place` to make sure this is undefined behaviour. The message in
the docs should be to watch out and not access the data after that, not
discussing when one maybe could get away with it O:-).
|
|
It is unclear if accessing an integer after `drop_in_place` has been
called on it is undefined behaviour or not, as demonstrated by the
discussion in
https://github.com/rust-lang/rust/pull/60766#pullrequestreview-243414222.
Avoid these uncertainties by using String which frees memory in its
`drop_in_place` to make sure this is undefined behaviour. The message in
the docs should be to watch out and not access the data after that, not
discussing when one maybe could get away with it O:-).
|
|
|
|
|
|
Let's try the auto-linking instead, since the relative ones don't work.
|
|
Co-Authored-By: Joe ST <joe@fbstj.net>
|
|
Since simulacrum suggested (on Discord) they're better there.
|
|
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
|
|
These are more than just `.into_iter().collect()`, so talk about some of their nuances.
|
|
`#[rustc_allocator]`
|
|
Succinctify splice docs
|
|
Add an unusual-conversion example to to_uppercase
Like how to_lowercase has ὈΔΥΣΣΕΎΣ.
|
|
Fix documentation of `Rc::make_mut` regarding `rc::Weak`.
Closes #60961
|
|
|
|
Like how to_lowercase has ὈΔΥΣΣΕΎΣ.
|
|
|
|
Box::into_vec: use Box::into_raw instead of mem::forget
`Box::into_raw` does, in one step, turn the `Box` into a raw ptr and avoid deallocation. Seems cleaner than separating the two.
Also, `mem::forget` gets the `Box` with a `noalias` argument, but it is not actually correct that this is an exclusive pointer. So a stricter version of Stacked Borrows would complain here. (I can't actually make Stacked Borrows that strict yet though due to other issues.)
|
|
Weak::into_raw
Hello
This is my first shot at #60728. I'd like to consult it a bit before moving further.
The biggest question I have is if this API makes sense. My motivation for it is to be able to store the `Weak` in `AtomicPtr`. For that I don't actually need for the pointer to point to the `T`, any pointer (maybe casted to `usize`) would be good enough, but this mirrors what `Arc` does and could be useful for other things too (like comparing if Arc and Weak point to the same thing without playing with the counts), while some opaque pointer wouldn't.
Some secondary questions, if this is deemed desirable are:
* The weak pointer may be dangling if it is created by `Weak::new()`. It would make sense to treat this as NULL, but that is incompatible with `T: ?Sized` ‒ both `new()` and `ptr::null()` are available only for sized types. The current implementation is therefore also available only for sized `T`s. It would be possible to allow `?Sized` if the API would be `fn into_raw(self) -> Option<NonNull<T>>` and `fn from_raw(NonNull<T>)`, but that's different API than `Arc` has. What would be preferred?
* There's a FIXME in my code about what I suspect could be UB. Is it really UB & how to get the pointer correctly? Is manual offsetting of the pointer the only way?
* Am I missing some other necessary thing around the feature gates and such?
* Is the documentation understandable? I know writing docs is not my strongest skill :-|.
Thinks I'd like to do as part of the PR, but are not yet done:
* Turn the referenced issue into tracking issue for the feature flag.
* Once the `sync::Weak` is considered reasonable, I'd do the equivalent for `rc::Weak`.
* This might call for few more tests than what is currently part of the documentation.
|
|
|
|
Co-Authored-By: Ralf Jung <post@ralfj.de>
|