Unify OsString/OsStr for byte-based implementations

[jethrogb]

As requested in #57860

r? @joshtriplett

[rust-highfive]

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_time:end:00f55755:start=1551827454640017285,finish=1551827455546996046,duration=906978761
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
Setting environment variables from .travis.yml
---
[00:04:52]    Compiling panic_unwind v0.0.0 (/checkout/src/libpanic_unwind)
[00:04:59] error: use has missing stability attribute
[00:04:59]   --> src/libstd/sys/unix/ext/ffi.rs:37:1
[00:04:59]    |
[00:04:59] 37 | pub use crate::sys_common::ffi_bytes::*;
[00:04:59] 
travis_time:end:12e1d180:start=1551827466555934200,finish=1551827766510703537,duration=299954769337
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:03134afc

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[jethrogb]

[00:04:59] error: use has missing stability attribute
[00:04:59]   --> src/libstd/sys/unix/ext/ffi.rs:37:1
[00:04:59]    |
[00:04:59] 37 | pub use crate::sys_common::ffi_bytes::*;

Why is a stability attribute required now? There wasn't one on the pub mod before. What do I even put here? unstable(std_internals)?

[joshtriplett]

This looks great!

I wish we could unify the doc comments as well, but even without that, this is a huge improvement.

[jethrogb]

I wish we could unify the doc comments as well, but even without that, this is a huge improvement.

I'll take suggestions on how to do that. As you can see, currently you need to use the respective modules, so they have to be different.

[joshtriplett]

On Wed, Mar 06, 2019 at 11:19:43AM -0800, jethrogb wrote: > I wish we could unify the doc comments as well, but even without that, this is a huge improvement. I'll take suggestions on how to do that. As you can see, currently you need to `use` the respective modules, so they have to be different.

Short of a macro generating `#[doc]` attributes, or making modules like `ffi_bytes` visible parts of the API, I don't know a good way to do that. The former seems potentially worth it; the latter I'd prefer ("this module exists only on certain platforms") but requires some discussion. Either way, I'd like to see *this* change go in, and we can consider further changes afterward.

[jethrogb]

Ok cool. Do you have any comments on the stability attribute issue?

[joshtriplett]

@jethrogb No, I don't know why that happens. I don't know why you'd need separate stability attributes here.

@rust-lang/libs?

[alexcrichton]

If the compiler requires a stability attribute then one needs to be applied. The compiler will often ask for a stability attribute on something that isn't actually used in stability attribute processing, but theoretically can be taken into account one day

[jethrogb]

Nevermind, I wasn't reading the error message correctly. Stability attributes are warranted here. Fixed now.

[Dylan-DPC-zz]

ping from triage @joshtriplett waiting for your review on this

[joshtriplett]

@bors r+

[bors]

📌 Commit 3bc4e76befab3e55bce7c29824f5d26b34deabba has been approved by joshtriplett

[alexcrichton]

Could this #[cfg] annotation perhaps be removed to simply #![allow(dead_code)] in the module? It's not really critical we actually delete dead code here and maintaining this #[cfg] over time seems like it may get burdensome (especially if it's duplicated with the above)

[jethrogb]

This is not possible because the code doesn't compile as-is on Windows - see https://travis-ci.com/rust-lang/rust/jobs/186485408

I don't think maintaining the cfg (which I put back) is problematic, lots of sys/ has code like this.

[jethrogb]

Made requested changes

[alexcrichton]

@bors: r=JoshTriplett

[bors]

📌 Commit fbc1aeda438c402af79e629fbac7f66dccdf9f8c has been approved by JoshTriplett

[tesuji]

Force-pushed. This PR needs to be approved again.

[alexcrichton]

@bors: r+

[bors]

📌 Commit 7b1fc49e5d424765dde8baf4f29d8fddc71abc41 has been approved by alexcrichton

[bors]

⌛ Testing commit 7b1fc49e5d424765dde8baf4f29d8fddc71abc41 with merge 987e145a46b12c6cd8dc5fc75817bc02fe95b764...

[bors]

💔 Test failed - status-appveyor

[jethrogb]

Fixed rustdoc. It's a pretty ugly hack because rustdoc can document code that doesn't otherwise compile. But this is how it used to work, so I'm not too keen on changing that now.

[alexcrichton]

@bors: r+

[bors]

📌 Commit 2079df1 has been approved by alexcrichton

[bors]

⌛ Testing commit 2079df1 with merge cb2f34d...

[bors]

☀️ Test successful - checks-travis, status-appveyor
Approved by: alexcrichton
Pushing cb2f34d to master...