Test specific to Windows host?

I'm working up a fix for a problem but it's specific to Windows;
the test won't behave the same way on Linux or whatever.
AFAICT the ways of expressing constraints are mostly target
based. Is there a way to express "run only on Windows host"?
Thanks,
--paulr

-target?

Otherwise can you explain more of what you’re trying to do?

-eric

The target is irrelevant. Clang running on Windows was hanging if the output-file path name was too long; I have a patch to make it return an error instead.

But another host OS won’t get an error for that case. So, the test behavior will vary by host OS. (Running Clang on Linux with a Windows target triple will not fail the same way because Linux has different path-length limits.) I’d rather constrain it to run only on a Windows host.

Or, hm, I suppose I could write the test to expect success and XFAIL: windows, but that seems like a perversion of the intent of XFAIL.

–paulr

Yeah. Don’t do that. It’ll just pass fine on other platforms, that seems ok.

-eric

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 done.

I could write it this way:

// RUN: not %clang –c foo.c –o pathname-too-long-for-Windows-to-handle.o

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 successfully). 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.

Is there a way to specify a host OS using REQUIRES? Or some other way to achieve the same effect? I’ll go with XFAIL unless something better shows up.

Thanks,

–paulr

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?

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.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

Please forgive my ignorance as I feel I missed something here.

Jeff

> 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
done.
>
> I could write it this way:
>
> // RUN: not %clang –c foo.c –o pathname-too-long-for-Windows-to-
handle.o
>
> 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
successfully).
> 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.

http://msdn.microsoft.com/en-
us/library/windows/desktop/aa365247(v=vs.85).aspx

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.
--paulr