Avoid cloning refcounted types during folding

[eggyal]

Addresses FIXME comment created in #78313

r? @lcnr

[lcnr]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 7e56cba8813a2b42dc593680b9c1c3b1c73495fc with merge e4a148d67d908f3377edf425472464853ddecbad...

[bors]

☀️ Try build successful - checks-actions
Build commit: e4a148d67d908f3377edf425472464853ddecbad (e4a148d67d908f3377edf425472464853ddecbad)

[rust-timer]

Queued e4a148d67d908f3377edf425472464853ddecbad with parent 44723c5, future comparison URL.

[rust-timer]

Finished benchmarking commit (e4a148d67d908f3377edf425472464853ddecbad): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf -perf-regression

[lcnr]

afaik Rc and Arc are really rarely used. I think that ideally we would avoid the copy of the inner data (which is actually the costly) part, but that requires some more complex (and probably unsafe) changes, so I am fine with this as is

@bors delegate+

[bors]

✌️ @eggyal can now approve this pull request

[eggyal]

@bors try @rust-timer queue

[rust-timer]

Insufficient permissions to issue commands to rust-timer.

[bors]

⌛ Trying commit 8aea3c54f92c39f74961ccb9c1a9df41abd0e060 with merge 61c0f6be8fa61b1982ad10d83cd8c32f4ea25e77...

[eggyal]

I think that ideally we would avoid the copy of the inner data (which is actually the costly) part, but that requires some more complex (and probably unsafe) changes, so I am fine with this as is

I've pushed a version that avoids those clones if possible. Can you request that rust-timer do a perf-run? Then obvs will need a thorough review. Or else am happy to roll back to the previous version.

[lcnr]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 2581670e9a9c7071de095dc5ec85165e9d108cb8 with merge 4f6356ed89d4f4988faf7d95a399ff6669718e4a...

[bors]

☀️ Try build successful - checks-actions
Build commit: 4f6356ed89d4f4988faf7d95a399ff6669718e4a (4f6356ed89d4f4988faf7d95a399ff6669718e4a)

[rust-timer]

Queued 4f6356ed89d4f4988faf7d95a399ff6669718e4a with parent 0b42dea, future comparison URL.

[rust-timer]

Finished benchmarking commit (4f6356ed89d4f4988faf7d95a399ff6669718e4a): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf -perf-regression

[lcnr]

alright, the impl looks good to me.

Please add some comments to explain what's going on here though.

I think that in the lines

let mut unique = Rc::from_raw(Rc::into_raw(self).cast());

it makes sense to explicitly mention the type of unique somewhere, either in Rc::<...>::from_raw, in cast::<...> or as the type of unique itself. Same for Arc.

r=me with some helpful comments

[eggyal]

@bors r=lcnr

[bors]

📌 Commit 5920a1d has been approved by lcnr

[lcnr]

good comments ❤️

[bors]

⌛ Testing commit 5920a1d with merge 1796de7...

[bors]

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing 1796de7 to master...

[rust-timer]

Finished benchmarking commit (1796de7): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression