Move OsStringExt and OsStrExt to std::os

[CDirkx]

Moves the OsStringExt and OsStrExt traits and implementations from sys_common to os. sys_common is for abstractions over sys and shouldn't really contain publicly exported items.

This does introduce some duplication: the traits and implementations are now duplicated in unix, wasi, hermit, and sgx. However, I would argue that this duplication is no different to how something like MetadataExt is duplicated in linux, vxworkx, redox, solaris etc. The duplication also matches the fact that the traits on different platforms are technically distinct types: any platform is free to add it's own extra methods to the extension trait.

[rust-highfive]

r? @m-ou-se

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

[CDirkx]

Because Buf and Slice now no longer live in a publicly exported module they can be marked as pub and repr(transparent) as normal.

[bors]

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

[m-ou-se]

I don't think we should be duplicating this. Duplication in std/src/sys has often led to badly maintained code in the past, where only some copies were updated. (E.g. documentation patches, etc.)

It might be good to have each platform opt-in to these extensions instead of just using not(windows) in sys_common/mod like it is now, but if we do that, we shouldn't be duplicating so much code and documentation.

[CDirkx]

I tried another approach of reusing code within std::os using #[path], like is done in sys. This removes the earlier duplication while moving OsStrExt/OsStringExt to the (in my opinion) more appropriate location with all the other extension traits.

One potential problem I could think of is that it is more easy to forget that a file is reused on other platforms, more so than in sys. A unix specific change to for example documentation would be incorrect on other platforms. Because of this I added a comment explicitly stating that the file is reused.

What are your thoughts on this approach? If you approve I could later look into if there are more files in std::os that can also be deduplicated this way.

[m-ou-se]

Thanks!

This looks very reasonable to me.

We could also have a os::common module or something for things used by multiple platforms, but in many ways, os::unix is that already.

@bors r+

[bors]

📌 Commit ad7b897 has been approved by m-ou-se

[bors]

⌛ Testing commit ad7b897 with merge dd94145...

[bors]

☀️ Test successful - checks-actions
Approved by: m-ou-se
Pushing dd94145 to master...