This is an archive of the discontinued LLVM Phabricator instance.

[llvm-objdump] Quote filename to fix windows test failure
AbandonedPublic

Authored by mmpozulp on Aug 4 2019, 10:08 PM.

Details

Reviewers
dyung
jhenderson
Summary

Attempts to fix buildbot failure
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/27368
which Douglas Yung alerted me to. Doug observed that:
2 tests modified r367776 are failing when run on a Windows bot.
It seems to be due to the [[FILE]] substitution escaping characters
and then expecting the output generated to match it which it does
not since things are then doubly escaped.

Event Timeline

mmpozulp created this revision.Aug 4 2019, 10:08 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 4 2019, 10:08 PM

@dyung @jhenderson do either of you know how I can test this on windows without having my own windows machine? It passes on my linux box but that's not where the failure was. Thanks :)

grimar added a subscriber: grimar.Aug 5 2019, 1:33 AM

It is not OK to have the bot red for a long time.
The builder mentioned (http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/27368)
is down for about 24h because of r367776 it seems.
The normal action would be to revert it, then retest with this patch and reland the fixed version I think.

I can help you with the testing on windows if needed.

mmpozulp abandoned this revision.Aug 5 2019, 2:03 AM

@grimar I reverted the commit, re-opened the original revision, and updated it with the '[[FILE]]' change. I'd love if you could test it on windows for me! Please use https://reviews.llvm.org/D62462.

Drive by comment, because I don't have time right now to verify my suggestion myself, but it's important to remember that on Windows, file paths are usually printed with backslashes in, i.e. "foo\bar\wibble.c" or whatever. %p and %t etc substitutions use backward slashes on Windows, unless you specify them as '%/p' and '%/t' or '%\p' and '%\t' (which force the slash direction IIRC). Note that this means that your current expansion looks like 'C:\an\absolute\path/Inputs/source-interleave.x86-64.c' or something like that. I don't think the double escaping is relevant - that's just an artifact of how FileCheck prints its messages, though you probably will need to be careful when sed gets involved (i.e. use %/t etc). I think your solution is going to need to be cleverer than this. I don't think quoting is what you want - those single quote will just try to match single quotes in the output, and have no effect on the escaping etc. You are probably going to need to be cleverer with your test. It probably needs to copy the source into a temporary file location or something like that, so that you can reference it as %t.c (or some equivalent), which allows you to use that path without slashes in your -DFILE check.

dyung added a comment.Aug 5 2019, 2:08 AM

I'm not at a Windows machine at the moment, so I can't test your fix, but I'm doubtful that it would actually work.

I think that in my experience trying to get "[[FILE]]" to work on Windows and non-Windows platforms is really hard. You might want to try another approach. Do you need to explicitly verify the entire path is present? Or would it be enough to just verify that the test filename appears in that line?

Ok thanks for the explanations @jhenderson and @dyung. I abandoned my attempt to use [[FILE]] in the tests. See https://reviews.llvm.org/D62462.