Tracking Issue for restructuring `sys_common`

[CDirkx]

The relationship between std::sys_common, std::sys and the rest of std is complex, with dependencies going in all directions: std depending on sys_common, sys_common depending on sys, and sys depending on sys_common and std. Ideally sys_common would be split into two and the dependencies between them all would form a dag.

There is a lot of interdependence between std, sys and sys_common, this is because sys_common contains several types of code:

• abstractions over the different platform implementations in std::sys (for example std::sys_common::mutex)
• code shared between platforms (for example std::sys_common::alloc)
• code that is not platform-dependent (for example std::sys_common::poison)

In order to reduce the interdependence, sys_common will be restructured:

• A new module sys::common is introduced; code that is shared by all platforms will be moved from sys_common to this new module.
• Code that is shared between some but not all platforms will be moved to sys and shared using #[path] instead.
• Code that is not platform-dependent will be moved out of sys_common to the appropriate place in std.

Ideally the end-result of this is sys_common again only containing platform-independent abstractions on top of sys.

[joboet]

This guideline came up whilst discussing #104329. However, I find the wording here to be confusing:

• Code that is not platform-dependent will be moved out of sys_common to the appropriate place in std.

sounds to me like the exact opposite of

the end-result of this is sys_common again only containing platform-independent abstractions on top of sys.

Furthermore, this part of the guideline is clear

• Code that is shared between some but not all platforms will be moved to sys and shared using #[path] instead.

but it is very limiting. Some code (like the generic fallback for Once) has no place inside sys since it is shared by not all, but most of the platforms. The current default seems to be the UNIX module, which is problematic since not everything is UNIX (e.g. Windows also uses that code). There definitely exists a need for a place for this kind of shared code to go, and sys_common is currently that place.

An alternate approach could be to move sys into sys_common and select (with cfg_if!) the required code for each feature there (selecting either the unique implementation in the former sys module or shared code living in sys_common). This would get rid of the unidiomatic #[path] imports, and also establish a strictly DAG-based structure (which seems to be a central idea of this guideline).