[PATCH] D79375: [FileCheck] Make invalid prefix diagnostics more precise

Joel E. Denny via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed May 6 10:13:31 PDT 2020


jdenny added inline comments.


================
Comment at: llvm/lib/Support/FileCheck.cpp:1887
+    if (Prefix.empty()) {
+      errs() << "error: supplied check prefix must not be the empty string\n";
       return false;
----------------
jhenderson wrote:
> jdenny wrote:
> > jhenderson wrote:
> > > How about `WithColor::error()` instead?
> > Good idea.  But should that be a separate patch that changes all FileCheck diagnostics at once?
> Yes, possibly. As most of these are new checks, that's why I brought it up, but at least one of them is moving, so that's fine.
OK, for now I'll leave that for a separate patch.


================
Comment at: llvm/lib/Support/FileCheck.cpp:1891-1893
+      errs() << "error: supplied check prefix must start with a letter and "
+             << "contain only alphanumeric characters, hyphens, and "
+             << "underscores: '" << Prefix << "'\n";
----------------
jhenderson wrote:
> jdenny wrote:
> > thopre wrote:
> > > jdenny wrote:
> > > > thopre wrote:
> > > > > Could you make ValidateCheckPrefix throw a DiagnosticError and print the error here?
> > > > That seems ok, but what's the motivation?  Is it a preferred style, or is there a technical advantage?
> > > Future proofing: the function could start getting used elsewhere so having the error message there makes sense. Feel free to disagree.
> > So the goal is to put the diagnostic that describes the constraint in the function that checks the constraint.  Makes sense to me.
> > 
> > Do you think it's worthwhile for `ValidateCheckPrefix` to be a separate function? It's so small, I'm thinking it does more to obfuscate the logic in `ValidatePrefixes` than to improve its readability.
> Passing an `Error` up the stack rather than relying on booleans seems like a good idea to me too (see my lightning talk from a couple of years ago which touched on this: https://www.youtube.com/watch?v=YSEY4pg1YB0).
> 
> I think it makes sense to fold in the function, but have no strong preference, if there's a good reason not to.
> Passing an Error up the stack rather than relying on booleans seems like a good idea to me too (see my lightning talk from a couple of years ago which touched on this: https://www.youtube.com/watch?v=YSEY4pg1YB0).

Nice talk.  Make sense.  You're talking about libraries there.  That means the `bool` return type for `FileCheck::ValidateCheckPrefixes` would need to change in addition to the local functions we were discussing.  `FileCheck::readCheckFile` is another that should change.  Especially because those changes would be library interface changes, I think they should go in a separate patch.

> 
> I think it makes sense to fold in the function, but have no strong preference, if there's a good reason not to.

I've folded in `ValidateCheckPrefix`.  I think the result is easier to read, but I'm happy to try something else if people disagree.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79375





More information about the llvm-commits mailing list