| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Remove trait LengthAtMost32
This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit.
I talked to @burrbull, he suggested me to finish his PR.
|
|
As a none-native speaker I stumbled upon this, looked it up and couldn't find a phrase, so I made my own assumption that "in any way" was meant (which is the meaning I would've deduced anyway)
|
|
Move A|Rc::as_ptr from feature(weak_into_raw) to feature(rc_as_ptr)
These were stabilized alongside the Weak versions, but having `feature = "weak_.."` on a fn definition for the non-weak pointers is potentially very misleading, especially in a review context where the impl header may not be immediately visible.
r? @RalfJung
@bors rollup=always
|
|
|
|
The thread that recovers the unique access to Arc inner value (e.g., drop
when ref-count strong reaches zero, successful try_unwrap), ensures that
other operations on Arc inner value happened before by synchronizing
with release operations performed when decrementing the reference counter.
When try_unwrap succeeds, the current thread recovers the unique access
to Arc inner value, so release is unnecessary.
|
|
|
|
to feature(rc_as_ptr)
These were stabilized alongside the Weak versions,
but having `feature = "weak_.."` on a fn definition
for the non-weak pointers is potentially very confusing.
|
|
|
|
|
|
Co-Authored-By: Ralf Jung <post@ralfj.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Stabilization of weak-into-raw
Closes #60728.
There are also two removals of `#![feature(weak_into_raw)]` in the `src/tools/miri` submodule. How should I synchronize the changes with there?
* I can ignore it for now and once this gets merged, update the tool, send a pull request to that one and then reference the changes to rustc.
* I could try submitting the changes to miri first, but then the build would fail there, because the attribute would still be needed.
I think the first one is the correct one, extrapolating from the contributing guidelines (even though they speak about breaking the tools and this should not break it, as extra feature should not hurt).
|
|
Resolve UB in Arc/Weak interaction (2)
Use raw pointers to avoid making any assertions about the data field.
Follow up from #72479, see that PR for more detail on the motivation.
@RalfJung I was able to avoid a lot of the changes to `Weak`, by making a helper type (`WeakInner`) - because of auto-deref and because the fields have the same name, the rest of the code continues to compile.
|
|
Use raw pointers to avoid making any assertions about the data field.
|
|
impl From<Cow> for Box, Rc, and Arc
These forward `Borrowed`/`Owned` values to existing `From` impls.
- `Box<T>` is a fundamental type, so it would be a breaking change to add a blanket impl. Therefore, `From<Cow>` is only implemented for `[T]`, `str`, `CStr`, `OsStr`, and `Path`.
- For `Rc<T>` and `Arc<T>`, `From<Cow>` is implemented for everything that implements `From` the borrowed and owned types separately.
|
|
make abort intrinsic safe, and correct its documentation
Turns out `std::process::abort` is not the same as the intrinsic, the comment was just wrong. Quoting from the unix implementation:
```
// On Unix-like platforms, libc::abort will unregister signal handlers
// including the SIGABRT handler, preventing the abort from being blocked, and
// fclose streams, with the side effect of flushing them so libc buffered
// output will be printed. Additionally the shell will generally print a more
// understandable error message like "Abort trap" rather than "Illegal
// instruction" that intrinsics::abort would cause, as intrinsics::abort is
// implemented as an illegal instruction.
```
|
|
|
|
Stabilizes #60728.
|
|
Use min_specialization in liballoc
- Remove a type parameter from `[A]RcFromIter`.
- Remove an implementation of `[A]RcFromIter` that didn't actually
specialize anything.
- Remove unused implementation of `IsZero` for `Option<&mut T>`.
- Change specializations of `[A]RcEqIdent` to use a marker trait version
of `Eq`.
- Remove `BTreeClone`. I couldn't find a way to make this work with
`min_specialization`.
- Add `rustc_unsafe_specialization_marker` to `Copy` and `TrustedLen`.
After this only libcore is the only standard library crate using `feature(specialization)`.
cc #31844
|
|
|
|
Add Arc::{incr,decr}_strong_count
This adds two `unsafe` methods to `Arc`: `incr_strong_count` and `decr_strong_count`. A suggestion to add methods to change the strong count in `Arc` came up in during review in https://github.com/rust-lang/rust/pull/68700#discussion_r396169064, and from asking a few people this seemed like generally useful to have.
References:
- [Motivation from #68700](https://github.com/rust-lang/rust/pull/68700#discussion_r396169064)
- [Real world example in an executor](https://docs.rs/extreme/666.666.666666/src/extreme/lib.rs.html#13)
|
|
|
|
- Remove a type parameter from `[A]RcFromIter`.
- Remove an implementation of `[A]RcFromIter` that didn't actually
specialize anything.
- Remove unused implementation of `IsZero` for `Option<&mut T>`.
- Change specializations of `[A]RcEqIdent` to use a marker trait version
of `Eq`.
- Remove `BTreeClone`. I couldn't find a way to make this work with
`min_specialization`.
- Add `rustc_unsafe_specialization_marker` to `Copy` and `TrustedLen`.
|
|
Rollup of 7 pull requests
Successful merges:
- #69041 (proc_macro: Stabilize `Span::resolved_at` and `Span::located_at`)
- #69813 (Implement BitOr and BitOrAssign for the NonZero integer types)
- #70712 (stabilize BTreeMap::remove_entry)
- #71168 (Deprecate `{Box,Rc,Arc}::into_raw_non_null`)
- #71544 (Replace filter_map().next() calls with find_map())
- #71545 (Fix comment in docstring example for Error::kind)
- #71548 (Add missing Send and Sync impls for linked list Cursor and CursorMut.)
Failed merges:
r? @ghost
|
|
Deprecate `{Box,Rc,Arc}::into_raw_non_null`
Per ongoing FCP at https://github.com/rust-lang/rust/issues/47336#issuecomment-586589016
See also https://github.com/rust-lang/rust/issues/47336#issuecomment-614054164
|
|
|
|
|
|
These forward `Borrowed`/`Owned` values to existing `From` impls.
impl<'a, B> From<Cow<'a, B>> for Rc<B>
where
B: ToOwned + ?Sized,
Rc<B>: From<&'a B> + From<B::Owned>,
impl<'a, B> From<Cow<'a, B>> for Arc<B>
where
B: ToOwned + ?Sized,
Arc<B>: From<&'a B> + From<B::Owned>,
|
|
For consistency with Weak
|
|
Co-Authored-By: Ralf Jung <post@ralfj.de>
|
|
|
|
Per https://github.com/rust-lang/rust/issues/47336#issuecomment-586589016
|
|
* Rename Weak::as_raw to Weak::as_ptr for consistency with some other
types.
* The as_ptr for a dangling Weak pointer might return whatever garbage
(and takes that advantage to avoid a conditional).
* Don't guarantee to be able to do `Weak::from_raw(weak.as_ptr())` (even
though it'll still work fine).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Amend Rc/Arc::from_raw() docs regarding unsafety
[This](https://stackoverflow.com/questions/59671647/is-it-safe-to-clone-a-type-erased-arc-via-raw-pointer) question on SO boils down to "is it safe to `::from_raw()` a `Rc<T>`/`Arc<T>` using a dummy `T` even if `T` is never dereferenced via the new `Rc`/`Arc`?". It almost never is.
This PR amends the docs of `from_raw()` regarding this point.
|
|
The memory fences used previously in Arc implementation are not properly
understood by ThreadSanitizer as synchronization primitives. This had
unfortunate effect where running any non-trivial program compiled with
`-Z sanitizer=thread` would result in numerous false positives.
Replace acquire fences with acquire loads when using ThreadSanitizer to
address the issue.
|
|
Remove `usable_size` APIs
This removes the usable size APIs:
- remove `usable_size` (obv)
- change return type of allocating methods to include the allocated size
- remove `_excess` API
r? @Amanieu
closes rust-lang/wg-allocators#17
|
|
|
