How to check paths in tests

One of the nice features of PathV2 is that we get "natural" paths on
Windows, but that does make testing them a bit harder. We go from

CHECK: foo/bar/zed

to

CHECK: foo{{/|\\}}bar{{/|\\}}zed

or

CHECK: foo{{/|\\\\}}bar{{/|\\\\}}zed

depending on whether the command being tested escapes \ or not. The
first question is why do we escape \? Do we expect some of the
command to print valid C string? Can we just print a single \
everywhere?

Second question/suggesting is to improve FileCheck to make this a bit
simpler. We could add a

CHECK-PATH: foo/bar/zed

that for now would just replace the / with a regular expression. Once
the transition to PathV2 is complete (and it is used everywhere), we
could make it stricter and check for / on unix and \ on windows.

Sean Silva suggests using something like {{{foo/bar/zed}}} to make the
substitution more local.

What do you guys think?

Cheers,
Rafael

I'm actually not sure I like this too much anymore. It's extremely cryptic.
My primary concern was something like:

CHECK: error: frobnication at foo/bar/baz

where I don't think you would want the test to just say

CHECK-PATH: foo/bar/baz

but rather want to check that "error: frobnication at" is there too.
However, having CHECK-PATH just replace `/` with the appropriate regex
would deal with this. It would lead to a slight loosening of cases like:

CHECK-PATH: error: division operator `/` at foo/bar/baz

would accept

CHECK-PATH: error: division operator `\\` at foo/bar/baz

but I think that this is not likely to be an issue in practice.

-- Sean Silva

What about:

CHECK: error: division operator `/` at [[@PATH:foo/bar/baz]]

Dmitri

I like this idea. It's similar to how we handle e.g. `[[@LINE+4]]` <
http://llvm.org/docs/CommandGuide/FileCheck.html#filecheck-expressions>.

-- Sean Silva