Make Rc<T>::deref and Arc<T>::deref zero-cost

[EFanZh]

Currently, Rc<T> and Arc<T> store pointers to RcInner<T> and ArcInner<T>. This PR changes the pointers so that they point to T directly instead.

This is based on the assumption that we access the T value more frequently than accessing reference counts. With this change, accessing the data can be done without offsetting pointers from RcInner<T> and ArcInner<T> to their contained data. This change might also enables some possibly useful future optimizations, such as:

• Convert &[Rc<T>] into &[&T] within O(1) time.
• Convert &[Rc<T>] into Vec<&T> utilizing memcpy.
• Convert &Option<Rc<T>> into Option<&T> without branching.
• Make Rc<T> and Arc<T> FFI compatible types where T: Sized.

[rustbot]

r? @jhpratt

rustbot has assigned @jhpratt.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[marmeladema]

Would it potentially enable those types to have an ffi compatible ABI? So that they could be returned and passed directly from /to ffi function, like Box?

[EFanZh]

Would it potentially enable those types to have an ffi compatible ABI? So that they could be returned and passed directly from /to ffi function, like Box?

I think in theory it is possible, at least for sized types, but I am not familiar with how to formally make it so.

[jhpratt]

r? libs

[joboet]

@EFanZh Is this ready for review? If so, please un-draft the PR.

[EFanZh]

@joboet: The source code part is mostly done, but I haven’t finished updating LLDB and CDB pretty printers. The CI doesn’t seem to run those tests.

[joboet]

No worries! I just didn't want to keep you waiting in case you had forgotten to change the state.
@rustbot author

[bors]

☔ The latest upstream changes (presumably #147197) made this pull request unmergeable. Please resolve the merge conflicts.

[camsteffen]

This may be way too late or useless. But maybe another way to split this up is to factor in a RawRc or whatever shared types/traits among Arc/Rc/etc, but without changing the actual implementation. And then make the optimization. The first part might be valuable on its own.

[bors]

☔ The latest upstream changes (presumably #147340) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[EFanZh]

This may be way too late or useless. But maybe another way to split this up is to factor in a RawRc or whatever shared types/traits among Arc/Rc/etc, but without changing the actual implementation. And then make the optimization. The first part might be valuable on its own.

@camsteffen: This is already done by splitting commits. The optimization is done in two standalone commits:

• Implement alloc::rc::{Rc,Weak,UniqueRc} with alloc::raw_rc types
• Implement alloc::sync::{Arc,Weak,UniqueArc} with alloc::raw_rc types

[camsteffen]

I think what you are doing is:

1. Create a new shared implementation that is optimized
2. Change the public types to use the new shared implementation

My suggestion is:

1. Refactor the public types to have a shared implementation without being optimized
2. Optimize the shared implementation

But again, this may not be worth it. Just a thought.