This is an archive of the discontinued LLVM Phabricator instance.

[FileCheck] Permit multiple -v or -vv
ClosedPublic

Authored by jdenny on Jun 25 2020, 2:14 PM.

Details

Summary

FILECHECK_OPTS was implemented so that a test runner, such as CI,
can specify FileCheck debugging options, such as -v and -vv.
However, if a test suite has a FileCheck call that already specifies
-v or -vv, then that call will fail if FILECHECK_OPTS also
specifies it.

For -vv, this problem already exists:

clang/test/CodeGen/aarch64-v8.2a-fp16-intrinsics-constrained.c

It's not yet clear if the -vv in that test was intentional, but this
usage shouldn't fail anyway. It's already true that FileCheck permits
-vv and -v together even though -vv implies -v.

Compare D70784, which fixed the same problem for -dump-input.

Diff Detail

Event Timeline

jdenny created this revision.Jun 25 2020, 2:14 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 25 2020, 2:14 PM

Tentative LGTM, but I'd like to see the test tidy-up separated out before formally approving.

llvm/test/FileCheck/verbose.txt
2

More than happy for you to make these tidy ups, but can you do them in a separate change, please? It makes it a little trickier to identify which cases existed before, versus which ones are new.

LGTM with James' suggestion

jdenny updated this revision to Diff 273725.Jun 26 2020, 7:25 AM

Changed RUN style to match what I now recall has been recommended in the past: | at end not beginning of line.

Extracted style changes of existing RUN lines to a parent patch, as requested.

thopre accepted this revision.Jun 26 2020, 7:46 AM

LGTM, thanks. Strange to have the pipe at the end but if that's the agreed upon practice so be it.

This revision is now accepted and ready to land.Jun 26 2020, 7:46 AM

@jhenderson, @thopre Thanks for the quick reviews!

Strange to have the pipe at the end but if that's the agreed upon practice so be it.

Well, a reviewer requested it at least once. @jhenderson, wasn't that you? Should we come to a broader consensus about this style, at least for FileCheck's test suite?

I don't think that point should delay these patches, but I'd be happy to go back and revise if we arrive at a different conclusion.

jhenderson accepted this revision.Jun 29 2020, 12:01 AM

@jhenderson, @thopre Thanks for the quick reviews!

Strange to have the pipe at the end but if that's the agreed upon practice so be it.

Well, a reviewer requested it at least once. @jhenderson, wasn't that you? Should we come to a broader consensus about this style, at least for FileCheck's test suite?

I don't think that point should delay these patches, but I'd be happy to go back and revise if we arrive at a different conclusion.

I personally recommend that style these days as a slight readability improvement. I don't think there's any particular widespread agreement on what is the best way though, and wouldn't ask for mass changes in existing tests. The idea is that from the line with the pipe on, you can tell that the complete command is written on that line, and that the next line will be a continuation, whilst the next line's extra 2 spaces of indentation show that it's a continuation from the previous line (and since it starts with a command is the start of that command). The alternative approach of the pipe being on the next line requires people to look at the next line to confirm whether or not all the command's arguments have been included.

LGTM.

I personally recommend that style these days as a slight readability improvement. I don't think there's any particular widespread agreement on what is the best way though, and wouldn't ask for mass changes in existing tests. The idea is that from the line with the pipe on, you can tell that the complete command is written on that line, and that the next line will be a continuation, whilst the next line's extra 2 spaces of indentation show that it's a continuation from the previous line (and since it starts with a command is the start of that command). The alternative approach of the pipe being on the next line requires people to look at the next line to confirm whether or not all the command's arguments have been included.

Thanks for the reminder. At the very least, this style seems consistent with other styles I've seen in LLVM. For example, before LLVM, I was used to the following style for operators in C/C++:

if (very_long_cond_1
    && very_long_cond2)
  statement;

But LLVM's style is:

if (very_long_cond_1 &&
    very_long_cond_2)
  statement;
This revision was automatically updated to reflect the committed changes.