Create separate sub-crate for CachePadded (second attempt)

[mgeier]

This is an alternative to #1069.

This simply creates a symbolic link to cache_padded.rs.

This way, crossbeam-utils is unaffected.

Fixes #1066, which contains related discussion.

This is also a proof of concept, some details still need to be ironed out.

[mgeier]

Are there any comments on this?

The goal of this new sub-crate was to avoid unnecessary MSRV bumps (for now using version 1.38), but this conflicts with the CI check for MSRV, which checks all sub-crates at once and fails because Rust 1.38 doesn't know yet about edition 2021.
Any ideas how to fix this?

[mgeier]

Just for reference: I have tried to come up with a hack that moves the maintenance burden to my crate: mgeier/rtrb#115

It's ugly, but it seems to work.
It still would be great if this could work out-of-the-box with crossbeam.

[taiki-e]

I'm thinking that if we put crossbeam-utils' atomic-related APIs behind a feature flag, adopt the approach I adopted in futures-rs (rust-lang/futures-rs#2811), revert the edition bump (c5c1361, a57e655), and disable unsafe_op_in_unsafe_fn in some crates, we can revert the MSRV bump, at least in crossbeam-utils and crossbeam-queue. Of course, the first one is a breaking change, but the master branch already has some unreleased breaking changes.

As for the currently proposed approach (adding a new CachePadded-only crate), I'm not sure it's worth having a new crate, considering that few users were using the cache-padded crate even before the deprecation.

[mgeier]

Yes, that sounds great!

considering that few users were using the cache-padded crate even before the deprecation.

This might be true, but I still consider it a very important foundational crate.

It would be great to have a widely usable and unrestricted common crate for that instead of everyone copying (parts of) the code to their own crates (like e.g. https://github.com/tqtrungse/omango-util/blob/master/src/cache_padded.rs).