[PATCH] D90631: [FileCheck] Use %ProtectFileCheckOutput in allow-unused-prefixes.txt

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 2 11:04:26 PST 2020


dblaikie added inline comments.


================
Comment at: llvm/test/FileCheck/allow-unused-prefixes.txt:3-7
+; RUN: %ProtectFileCheckOutput FileCheck --allow-unused-prefixes=true  --check-prefixes=P1,P2 --input-file %S/Inputs/one-check.txt %S/Inputs/one-check.txt 
 
 ;; Note: the default will be changed to 'false', at which time this run line
 ;; should be changed accordingly.
+; RUN: %ProtectFileCheckOutput FileCheck --check-prefixes=P1,P2 --input-file %S/Inputs/one-check.txt %S/Inputs/one-check.txt 
----------------
mtrofin wrote:
> dblaikie wrote:
> > mtrofin wrote:
> > > dblaikie wrote:
> > > > I /think/ these two don't need it, since their output doesn't feed into another FileCheck command (so I assume it's intended to be seen/understood by a human) - but I haven't looked closely at the test. Is there some reason these two would need stabilized/non-customizable output?
> > > What if the user sets --allow-unused-prefixes in their env?
> > My guess would be that that wouldn't be reasonably supported through `FILECHECK_OPTS` - in the same way that passing `--check-prefixes=SOMETHING` via `FILECHECK_OPTS` wouldn't be usefully supported either. `FILECHECK_OPTS` is for things like `--color` and `--dump-*` flags, I believe.
> The 2 tests are that FileCheck passes - i.e. it returns 0. So I'd argue they are similar to the other cases, in that we rely on the user not accidentally messing with the options.
That property (that FileCheck passes) is true of every test that uses FileCheck (ie: lots of LLVM tests), not only the ones intended to check FileCheck's behavior.

Perhaps @jhenderson has some perspective here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90631



More information about the llvm-commits mailing list