Forward lines from stderr of child process to stdout on the same thread, instead of spawning a thread

[dpaoliello]

cc-rs was redirecting output from stderr of its child processes to a pipe, which was then being read on dedicated thread and written to stdout with a wrapper message.

This pattern caused a few issues:

• It created a dependency from cc-rs to libc when building the Rust standard library with optimized compiler intrinsics, resulting in the Rust build breaking (see Upgrading to cc@1.0.84 breaks libstd bootstrap #913).
• With the parallel feature enabled, there was no synchronization between different child processes writing to the pipe, potentially resulting in corrupted output.
• The thread that was forwarding the lines was wasted, since the main thread was blocking waiting for the child process(es) to exit anyway.

The fix for this is to forward output from stderr to stdout on the current thread. For the parallel feature this required implementing a non-blocking version of BufReader::read_until that consumes whatever data is available and then continues.

Fixes #913

[NobodyXu]

There're a lot of changes here, it might take me some time to review it.

[dpaoliello]

If it helps, I have a build of the Rust toolchain that uses this: https://github.com/rust-lang/rust/actions/runs/7719025147/job/21041489650?pr=119199

[dpaoliello]

@NobodyXu I'm going to have to rework this, since there are two issues:

The first, fixable, issue is that BufReader.fill_buf will only read more if all data in the buffer has been consumed - so if we don't consume everything then fill_buf won't read any more data and so each subsequent call to fill_buf will keep returning the same data.

The second, fundamental, issue is that read will block until data is available or the child exits - so in parallel mode we'll block waiting for the first child's stderr to return something or until that process exits.

There's a few different ways that we can address these:

1. Accept the limitations of the second issue, and workaround the first issue by replacing the BufReader with our own calls to read into a Vec (as you had suggested for the non-parallel code).
2. Give up on trying to forward the stderr output while the children are running, and instead forward them all once the child has exited.
3. Do something like the original code but create one thread per child instead of using a single thread.

Thoughts?

[NobodyXu]

The second, fundamental, issue is that read will block until data is available or the child exits - so in parallel mode we'll block waiting for the first child's stderr to return something or until that process exits.

If you bring back os_pipe, then you could read without blocking.

[dpaoliello]

@NobodyXu ok, I think I have this figured out: for Unix, I'm setting the pipe as non-blocking and checking for WouldBlock. For Windows, I'm using PeekNamedPipe to check for data and returning early if there is none.

I also removed the BufReader and switched to directly reading into the Vec.

[NobodyXu]

Thanks, it overall LGTM, just two nitpicks I want to discuss with you before I approve and merge it.

[NobodyXu]

Thanj you!

[dpaoliello]

Can we please get a release with this change?

[NobodyXu]

Yes, I definitely want to have a release.

There's a regression #902 that needs to be fixed before a release can be done.