Page MenuHomePhabricator

Fix external-names.c test when separator is \\
ClosedPublic

Authored by michaelplatings on Dec 30 2019, 12:55 AM.

Details

Summary

This fixes the following failure:

C:\[...]\llvm\tools\clang\test\VFS\external-names.c:34:26: error: CHECK-DEBUG-EXTERNAL: expected string not found in input
// CHECK-DEBUG-EXTERNAL: ![[Num]] = !DIFile(filename: "{{[^"]*}}Inputs{{.}}external-names.h"
                         ^
[...]
<stdin>:42:54: note: possible intended match here
!10 = !DIFile(filename: "C:/[...]\\llvm\\tools\\clang\\test\\VFS\\Inputs\\external-names.h", directory: "")

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptDec 30 2019, 12:55 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
michaelplatings edited the summary of this revision. (Show Details)Dec 30 2019, 12:55 AM
miyuki accepted this revision.Dec 30 2019, 3:10 AM

LGTM. Let's wait for someone else to approve (or commit after holidays if no one objects).

This revision is now accepted and ready to land.Dec 30 2019, 3:10 AM
rnk accepted this revision.Dec 30 2019, 9:39 AM

lgtm, but why doesn't this show up on existing clang windows bots? For example:
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/13276

IIRC clang often joins paths with /, so maybe this separator is always / upstream. Do you have some downstream patch or setting to change that?

amccarth accepted this revision.Dec 30 2019, 11:07 AM

I've made a similar change in several other tests, but this test works for me without this change. I'm trying to understand why, but I don't see any harm in landing this.

I'm still not seeing how the backslashes got in there for you. They don't happen for me. It looks like these paths come (almost) directly from the temp .yaml files created by the sed commands at the beginning of the test, so--for these particular tests--I'd expect forward slashes regardless of platform.

I made a set of interelated VFS changes for Windows compatibility. The last of those was on December 18. Could your repo be older than that?

Thanks for accepting.
The repo is up to date. I guess the reason the failure hasn't happened with the build bots is that our downstream test setup differs somewhat from the norm - our test runner imports lit.discovery & lit.LitConfig directly rather than using the command line interface. I've had a hunt for what the exact difference might be but haven't been able to find it.

This revision was automatically updated to reflect the committed changes.

It would surprise me if the different test config is cause here. The path is assembled entirely in the code, so it should be consistent. If you had a systemic problem introduced by test config, I'd expect more of the VFS tests to fail.

Anyway, if you're back in business, that's great, but I can't promise future VFS changes won't cause similar problems for you.