[llvm-dev] Confusing FileCheck check-label documentation

[via llvm-dev]

The documentation is incorrect there; it's not that the *line* cannot be matched, but that the pattern in the directive cannot be matched by other directives.
"cannot also be matched…" is kind of awkwardly written as well, the intent is that each CHECK-LABEL pattern ought to be unique in the input.

This reminds me that I was supposed to overhaul the FileCheck documentation…  which task seems to have fallen off my to-do list, I will put it back.
HTH,
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Peter Waller via llvm-dev
Sent: Tuesday, July 30, 2019 11:00 AM
To: llvm-dev at lists.llvm.org; nd
Subject: [llvm-dev] Confusing FileCheck check-label documentation


The FileCheck documentation states of CHECK-LABEL:

> It is treated identically to a normal CHECK directive except that FileCheck makes an additional assumption that a line matched by the directive cannot also be matched by any other check present in match-filename;

However:

$ cat > fchecktest.txt

#CHECK-LABEL: flang2
#CHECK: foo baz

flang1 foo bar
flang2 foo baz

$ grep -v -e '^#' fchecktest.txt | bin/FileCheck fchecktest.txt

(passes)

The behaviour of the above suggests contrary to the documentation - that foo baz can indeed be matched against the label line "flang2", i.e. check-label does not consume the whole line as the docs seem to imply.

I believe that FileCheck is working as intended and that the docs are just a bit confusing. Is that right?

The use-case is matching flang1 and flang2 invocations by the clang driver in -### output, and the intent is to be able to match something appearing in one without accidentally matching the other.

- Peter
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190730/304f4670/attachment.html>