r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

r? @Amanieu

In theory we could even make these Relaxed since we don't promise any memory ordering and it's the user's responsibility to use an Acquire fence if they need one. However there might also be code out in the wild which relies on Acquire or SeqCst ordering here. Is there a specific reason for making this change (such as a performance concern)?

Cloning an Arc increments the strong counter (and cloning a Weak the weak counter) with Relaxed ordering, so if we're going to clean up these unnecssary SeqCst orderings, we should probably just make them Relaxed.

It looks like Relaxed also matches what C permits for std::shared_ptr<T>::use_count: https://en.cppreference.com/w/cpp/memory/shared_ptr/use_count.

Is there a specific reason for making this change (such as a performance concern)?

Not really a specific reason, it just seemed unnecessary, and one of the library teams goals cited recently was to remove needless SeqCst orderings.

However there might also be code out in the wild which relies on Acquire or SeqCst ordering here.

Relying on Acquire seems plausible, but relying on SeqCst seems incredibly questionable and anyone doing so should really be using a fence.

I think this change is fine to merge, we can leave the decision to switch to Relaxed to a later PR.

@bors r

📌 Commit 7e93032 has been approved by Amanieu

⌛ Testing commit 7e93032 with merge e209e85...

☀️ Test successful - checks-actions
Approved by: Amanieu
Pushing e209e85 to master...

Finished benchmarking commit (e209e85): comparison url.

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

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

@rustbot label: -perf-regression