[PATCH] D77227: [RFC][FileCheck] Require colon immediately after CHECK directives

Joel E. Denny via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 2 10:50:07 PDT 2020


jdenny added a comment.

In D77227#1957332 <https://reviews.llvm.org/D77227#1957332>, @probinson wrote:

> I believe where we're headed is that the (whitespace or ending with `[#/;*!]`) rule is how we'll identify directives that we expect the user *intended* to be directives for FileCheck to act on.  If we then find syntactic errors (multiple suffixes, missing colon) we'll report those as errors.


I'm not sure if I'm reading this correctly.  Which of the following do you intend?

A. This new rule constrains where FileCheck recognizes malformed directives for diagnostics.

B. This new rule constrains where FileCheck recognizes both (1) malformed directives for diagnostics and (2) well formed directives for execution.

I thought we were planning A.

I think the only change from A to B is to (at least theoretically) create a new class of malformed directives that won't be executed, and they happen to also be ones we cannot diagnose under this new rule.  We would need the mode you describe below to diagnose these, but those diagnostics would apparently be plagued by false positives.

If that new class of malformed directives doesn't exist in practice, then A = B in practice, so we might as well stick with A to avoid the difference in the future.

B seems to have no advantage.

> Would it be useful to have one of the verbose modes report directive matches that *don't* satisfy the (whitespace or `[#/;*!]`) rule?  It would report all the false positives, but could be really helpful in diagnosing a malfunctioning test.  And it would be easy to add this, as we've already analyzed the line to see if it's one we should act on.

I think such a mode would be helpful.  This is the type of configurability I was thinking of.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77227





More information about the llvm-commits mailing list