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

[EFanZh]

But the largest thing that stands out to me is that there's a lot of tiny functions. Although they have descriptive names and are documented, it made it somewhat harder to follow for me. For the ones used only once, it might make sense to inline them for readability.

@thaliaarchi: Do you mean the allocation functions? I have checked those functions, most functions are used more than once, and the function that are used once are used for unifying non-generic codes used in generic functions.

@rustbot ready

[bors]

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

[bors]

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

[bors]

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

[joboet]

This PR is way too large for me to review. Is there any way you could split this up? E.g. by moving the Arc changes to a different PR...

[EFanZh]

@joboet: The majority codes are in alloc::raw_rc module, which has to be submitted with at least one of alloc::rc and alloc::sync changes, otherwise they will be unused codes. Do you accept that I split this PR into these two PRs?

1. PR containing alloc::raw_rc + alloc::rc changes: this one will still contain a large chunk of code, which I don’t have a good way to further split.
2. PR containing alloc::sync changes.

[thaliaarchi]

Alternatively, an approach to consider, if splitting horizontally isn’t feasible, you could split it vertically: Split it into a commit history of discrete, atomic steps progressing towards the goal of the PR. Even if it needs to be merged all at once, this can aid reviewing.

I know the Rust project prefers smaller PRs, though, so that should be preferred if possible, but the approaches could be combined.

[joboet]

@joboet: The majority codes are in alloc::raw_rc module, which has to be submitted with at least one of alloc::rc and alloc::sync changes, otherwise they will be unused codes. Do you accept that I split this PR into these two PRs?

1. PR containing `alloc::raw_rc` + `alloc::rc` changes: this one will still contain a large chunk of code, which I don’t have a good way to further split.

2. PR containing `alloc::sync` changes.

That sounds very reasonable!

[EFanZh]

@joboet: I have split this PR into two commits:

• The first commit contains alloc::raw_rc and alloc::rc changes, which has also be submitted separately in Make Rc<T>::deref zero-cost #141348.
• The second commit contains alloc::sync changes.