[PATCH] D47114: [FileCheck] Implement -v and -vv for tracing matches

Joel E. Denny via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 9 12:45:09 PDT 2018


jdenny added a comment.

In https://reviews.llvm.org/D47114#1189632, @george.karpenkov wrote:

> > LIT_DEBUG=2: FileCheck is passed -v
>
> In order to support this, can you post a new patch updating this one to have a default of verbose to be set via an environment variable? (FILECHECK_VERBOSE?)


I think FILECHECK_FLAGS (and potentially LIT_FLAGS) is better than implementing separate environment variables, like FILECHECK_VERBOSE, for every FileCheck (or lit) command-line flag someone might want to control via the environment.  I think it's obvious why that would be easier to implement and to remember, and I haven't heard an argument for why one environment variable per flag is better.

I'm fine with LIT_DEBUG as a more convenient way to specify a common set of debug-related flags.  However, when LIT_DEBUG is set, lit could pass flags to FileCheck via FILECHECK_FLAGS.

>> That is, if flags are processed left-to-right, then LIT_DEBUG prepends to *_FLAGS. What do you think?
> 
> I am not sure what do you mean, I think supporting LIT_FLAGS is a separate feature for a separate use case.

Yes, but the relevance is as follows.  When LIT_DEBUG is set, lit needs some way to pass flags to FileCheck.  I suggest FILECHECK_FLAGS as a clean way to do that.  If we're going to have FILECHECK_FLAGS, then we should have LIT_FLAGS for consistency, and both will help in use cases where LIT_DEBUG doesn't suffice.

And we must consider what happens when LIT_DEBUG's setting conflicts with other environment variables.  That's the motivation for the text about prepending that you quoted above.  These kinds of conflicts will happen regardless of whether we take the LIT_FLAGS/FILECHECK_FLAGS approach or the one-environment-variable-per-flag approach.  But the above text is assuming the former approach.


Repository:
  rL LLVM

https://reviews.llvm.org/D47114





More information about the llvm-commits mailing list