[lld] r268345 - Temporarily disable this test on llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast

[Robinson, Paul via llvm-commits]

> >> > We can try to move the bot to a shorter build directory path.
> >>
> >> If you "fix" the bot to use short paths, we'll never find these
> things...
> >> The short/long path thing is just a fact of life on Windows and we do
> >> need to tolerate it.
> >
> >
> > I tend to agree. Hopefully Rafael's archive patch will actually solve
> the
> > issue.
> >
> > There is a bit of a slippery slope though, as every test needs *some*
> amount
> > of file path length slack. The question is how much is reasonable.
> > For example, we could put the build dir at a path of length `PATH_MAX -
> 1`.
> > Obviously then we won't be able to even create `$BUILDDIR/lib/` or
> whatnot.
> > Ultimately we might settle at `PATH_MAX - 42` which is enough for the
> build
> > (`42` is just for the sake of choosing a number; I don't know the actual
> > number). So then does this mean that our tests basically assume that we
> have
> > 42 characters of slack on customer machines?
> >
> > I'm not sure what the right tradeoff is. In the case of a test like this
> > that essentially "doubles" the number of characters in a path, it is
> > probably clear that we need to be careful about it. But what about a
> test
> > that needs 43 extra characters? 47 extra characters? 127 extra
> characters?
> >
> > Thoughts?
> >
> > -- Sean Silva

My thought is, Windows has a specific breaking point between short & long
forms, which is much shorter than any other modern OS's PATH_MAX.  If we
had a bot where the root of the LLVM checkout was past the Windows short 
max, I bet we'd smoke out 90% of the problems.  The last 10% would be where 
filespec A fit into the short size but generated filespec B=A+"otherstuff" 
slid past it; those are always going to be hard to find.

It would at least be better coverage than we have now, and seems less
prone to overrun problems than going for PATH_MAX-N.
--paulr