Spotted some problems in the Driver's PrepareCommandsForSourcing while
helping a colleague track another problem.
- One error case was not handled because there was no else clause.
Fixed by switching to llvm's early-out style instead of nested
if (success) { } else { } cases. This keeps error handling close
to the actual error.
- One call-site failed to call the clean-up function. I solved this
by simplifying the API. PrepareCommandsForSourcing no longer requires
the caller to provide a buffer for the pipe's file descriptors and to
call a separate clean-up function later. PrepareCommandsForSourcing
now ensures the file descriptors are handled before returning.
(The read end of the pipe is held open by the returned FILE * as
before.)
I also eliminated an unnecessary local, shorted the lifetime of another,
and tried to improve the comments.
I wrapped the call to open the pipe to get the #ifdefs out of the
mainline. I replaced the close/_close calls with a platform-neutral
helper from llvm::sys for the same reason. Per discussion on the
review, I'm leaving the fdopen call to use the spelling that Windows
has officially deprecated because it still works it avoids more #ifdefs.
Do you think it would be possible to use llvm::Process::SafelyCloseFileDescriptor here? It looks like that still uses close (without the _) on windows, which we are trying hard to avoid here, but I'm not sure why. I know close is technically deprecated on windows, but AFAIK the only thing deprecated about it is the name, and otherwise it works correctly.
(If that works, I'd even consider removing this function entirely, as the only thing it does extra is clear the fd, but that does not seem necessary since we're now calling it immediately before we return (and the fds go out of scope anyway)).