[cfe-dev] Test specific to Windows host?
Paul.Robinson at am.sony.com
Thu Mar 7 08:46:23 PST 2013
> On Wed, Mar 6, 2013 at 4:05 PM, Robinson, Paul
> <Paul.Robinson at am.sony.com> wrote:
> > I can write it this way:
> > // RUN: %clang –c foo.c –o pathname-too-long-for-Windows-to-handle.o
> > // XFAIL: windows
> > This will show as an expected failure when run on Windows, and pass
> > everywhere else. Not what XFAIL was intended for, but it gets the job
> > I could write it this way:
> > // RUN: not %clang –c foo.c –o pathname-too-long-for-Windows-to-
> > This will pass on Windows (because clang will return an error) but
> fail on
> > other hosts e.g. Linux (because clang will compile the test
> > Nobody will be happy unless I can find a way to make the test be
> skipped on
> > everything except Windows.
> > Grasping at straws, I tried adding
> > // REQUIRES: windows
> > but that suppresses the test on Windows as well as Linux.
> Perhaps I'm missing the point, but isn't the failed self-test
> indicating a [platform] problem with Clang/Windows? Which means it
> could fail in the field? Shouldn't the problem be fixed rather than
> working around the one thing that's suppose to catch the failure?
The _current_ problem is that Clang will hang in this situation.
I'm about to put out a patch that will turn the hang into an error.
I am banging my head against the wall about how to fit a test into
the Clang/LLVM test infrastructure in a way that won't break bots
on other platforms.
> Perhaps Clang on Windows should call GetShortPathName? Or maybe use
> the \\?\ prefix in its path routines on Windows? With the latter, the
> path can be 65K and each component has a limit of MAX_PATH.
A more ambitious fix could take that approach, yes. And that fix
would permit removing XFAIL from my test, which makes me less
unhappy about using the XFAIL hack in the first place.
But at the moment I just want Clang not to hang on me.
More information about the cfe-dev