[PATCH] D60389: FileCheck [9/12]: Add support for matching formats

Thomas Preud'homme via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 11 04:48:31 PST 2019


thopre planned changes to this revision.
thopre added a comment.

Uploading the current status of this patch. I know there are still issues (in particular add more unittests), and I'll address them.



================
Comment at: llvm/docs/CommandGuide/FileCheck.rst:601
+
+The syntax of a numeric substitution is ``[[#%<fmtspec>:<expr>]]`` where:
 
----------------
jhenderson wrote:
> I'm getting confused by the syntax here not matching the syntax above for defining a numeric variable.  Aren't the two essentially the same syntax, just with different parameters missing? If I'm not mistaken they can be unified to `[[#%<fmtspc>,<NUMVAR>:<expr>]]` where <expr> says what this matches against (if specified), <NUMVAR> says what numeric variable to store the result in (if specified) and fmtspec defines the format of the expression (if any) and that stored in the variable (if any).
> 
> Aside: does [[#%X]] match a hex number, but not store it?
That's a mistake, well spotted. Yes [[#%X]] matches an hex number in capital letters but does not store it.


================
Comment at: llvm/test/FileCheck/string-defines-diagnostics.txt:28-29
 ; Invalid variable name: starts with a digit.
-RUN: not FileCheck -D10VALUE=10 --input-file %s %s 2>&1 \
-RUN:   | FileCheck %s --strict-whitespace --check-prefix ERRCLIFMT
+RUN: not FileCheck -D10VALUE=10 -input-file %s %s 2>&1 \
+RUN:   | FileCheck %s --strict-whitespace -check-prefix ERRCLINAME
 
----------------
jhenderson wrote:
> Please re-add the second dash, to remain consistent with other tests in this file (why did you change it?)
The patch initially only changed ERRCLIFMT into ERRCLINAME. Later when rebasing it after the updated previous patch with the -- syntax I missed the - to -- change when resolving conflicts in this file. Same for all other issues you mention in an earlier patch and end up in a later patch: either incorrect merging (happens a lot when the conflict spans many lines because it's easy to miss something) or it's new code and I forgot to apply some fix on there as well (for example the eg -> e.g. fixes).

In other word, my apologies for making you repeat your point, it's due to being absent-minded at times.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60389/new/

https://reviews.llvm.org/D60389





More information about the llvm-commits mailing list