[PATCH] Windows hang with long filename

[Robinson, Paul]

This is basically the Windows version of r176226; it avoids a
hang when certain issues arise with an output filename.
We found this because Clang would hang because the output file
pathname exceeded the Windows limit of 260 characters.
Yes, I know the context around the fix is about creating the
parent directory; but that's the loop where the hang occurs.

Murphy consequence #1:  I could not find any LLVM tool that used
unique_file(), only Clang uses this AFAICT.  So the test is written
for Clang, which means it has to go in the Clang suite instead of
the LLVM suite.

Murphy consequence #2:  The problem occurs only on Windows, but the
LIT test system apparently has no way to describe a host-specific
test.  Linux and others have different limits on output file paths,
so you cannot expect the same behavior across all hosts.  I was able
to craft a test that did exercise the problem on Windows without
bumping into different problems on Linux, but the only way I could
get it to be cross-platform is to mark it XFAIL: win32, with a big
comment explaining why.

I am resigned to the perverseness of the test.  I'm willing to have
the test accepted on condition that I file a bug against the test
system for being unable to constrain a test based on the host platform.
I'm also willing to have the test rejected as too stupid to live.
(But don't ask me to implement the \\?\ stuff.)

Thanks,
--paulr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: WinPath-fix.diff
Type: application/octet-stream
Size: 1085 bytes
Desc: WinPath-fix.diff
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130312/f7b5ea5e/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WinPath-test.diff
Type: application/octet-stream
Size: 1780 bytes
Desc: WinPath-test.diff
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130312/f7b5ea5e/attachment-0001.obj>