Fix several bugs in r221220's new program finding code.
authorChandler Carruth <chandlerc@gmail.com>
Tue, 2 Dec 2014 00:52:01 +0000 (00:52 +0000)
committerChandler Carruth <chandlerc@gmail.com>
Tue, 2 Dec 2014 00:52:01 +0000 (00:52 +0000)
commitec8406d8f43c8e459034f8bddf3112c26a31a81b
tree49a3cd41f226db127888aeb3e6138a753214ec09
parent4742353414b55f12884f1ca783b0492ac8c6b189
Fix several bugs in r221220's new program finding code.

In both the Unix and Windows variants, std::getenv was called and the
result passed directly to a function accepting a StringRef. This isn't
OK because it might return a null pointer and that causes the StringRef
constructor to assert (and generally produces crash-prone code if
asserts are disabled). Fix this by independently testing the result as
non-null prior to splitting things.

This in turn uncovered another bug in the Unix variant where it would
infinitely recurse if PATH="", or after this fix if PATH isn't set.
There is no need to recurse at all. Slightly re-arrange the code to make
it clear that we can just fixup the Paths argument based on the
environment if we find anything.

I don't know of a particularly useful way to test these routines in
LLVM. I'll commit a test to Clang that ensures that its driver correctly
handles various settings of PATH. However, I have no idea how to
correctly write a Windows test for the PATHEXT change. Any Windows
developers who could provide such a test, please have at. =D

Many thanks to Nick Lewycky and others for helping debug this. =/ It was
quite nasty for us to track down.

llvm-svn: 223099
llvm/lib/Support/Unix/Program.inc
llvm/lib/Support/Windows/Program.inc